Calculate TimeZoneInput from timestamps

[sffc]

Pending #528, we will likely require time zones to be fully resolved into GMT offsets and metazones. However, the reality is that people will want to hand ICU4X a timestamp, and get a localized result out the other end. Our organization has the expertise to implement these conversions, and I think we should release libraries to perform them. Of course, they should be modular and stand to the side of ICU4X.

What we should implement is, I think, rather straightforward:

• Input: Timestamp (seconds since epoch) and BCP-47 time zone identifier*
• Output: Metazone, GMT offset, and variant (input to #528)

* I would like to take the BCP-47 time zone identifier as input because I want to encourage the use of the small, fixed-width, lightweight types within ICU4X. However, since most people will be using IANA identifiers, we should also provide a library on the side that can convert from IANA identifier to BCP-47 identifier.

We should also think about how this relates to the ISO-8601 and Temporal data models. In particular, we may want to match our data model to strings such as:

1. 2021-03-05T07:49:02Z is a timestamp in UTC
2. 2021-03-05T00:49:02-0700 is the same timestamp but with a GMT offset
3. 2021-03-05T00:49:02-0700[America/Denver] is a zoned datetime; the GMT offset should serve as a hint to help resolve potential conflicts near variant transitions (daylight savings time)

In the end, we also need the ISO date to feed into #534, so the time zone resolution layer should make sure to retain that information when possible.

[sffc]

Discussion 2021-03-12:

• This component will need DataProvider and is unlikely to be useful outside the context of ICU4X
• We will release this as an ICU4X utility, living in the ICU4X repo
• This component is more closely tied to ICU4X than, say, TinyStr, so we shouldn't tie this conclusion to conclusions about TinyStr

[sffc]

I think we should seriously consider making a TimeZone class with a similar API as Temporal.TimeZone, which has two benefits:

1. We can follow a pre-existing design
2. Helps ICU4X be a basis for Temporal implementations

Read more: https://github.com/tc39/proposal-temporal/blob/main/docs/timezone.md

CC @nordzilla

[nordzilla]

I will incorporate this into Friday's discussion.

[sffc]

Note that we will want to support both directions. In ICU these are Calendar::setTime and Calendar::getTime.