Support Temporal

[sffc]

We will be supporting many pieces of code required to implement Temporal, in particular the time zone and calendrical calculations. We need to decide how we will expose a Temporal-compatible API in Rust and/or JavaScript.

[sffc]

I thought we had this conversation going somewhere else, but I couldn't find it, so I'll start it fresh here.

I made a little flow chart of calendar-dependent operations in the Temporal spec:

CalendarHasMidYearEras is coming in tc39/proposal-intl-era-monthcode#77.

I plan to make functions in ICU4X implementing each one of the five lavender-colored bubbles in that diagram, and one mega function to implement the orange-colored bubbles (described in #6790 (comment)).

Possible API for the left two lavender bubbles:

#[non_exhaustive]
pub struct CalendarEraInfo {
    supports_eras: boolean,
    has_mid_year_eras: boolean,
}

trait Calendar {
    // new trait function. question: should it take &self?
    fn era_info() -> CalendarEraInfo;
}

CalendarISOToDate is already supported with Date::new_from_iso.

CalendarDateAdd is already partially implemented by the doc-hidden Date::add, but I am thinking of changing it in a few ways:

1. Remove the type parameter from DateDuration
2. Make the DateDuration have unsigned fields plus a single sign bit
3. Add an overflow option to Date::add
4. Maybe remove the weeks fields since Temporal says it is always identical to 7 days
5. Maybe rename some things along the way

Adjustments to Date::until:

1. Remove smallest_unit. The Temporal spec only passes largest_unit into this AO and handles smallest_unit in a rounding function that is separate from the calendar-dependent part (one that ends up calling back into Date::add).
2. Hmm, since largest_unit could be weeks, maybe I should leave weeks in DateDuration.

Does this API surface (what sits between ICU4X and Temporal_rs or SpiderMonkey) make sense to everyone?

@Manishearth @nekevss @anba @ptomato

[nekevss]

The overview and general API makes sense to me. My initial reaction for the trait function is that it should take &self. CalendarDateAdd 1-3 sounds good to me as well.

My preference would be a weeks field on the DateDuration to be present but that could ultimately be worked around if you decide to go without the field.