Add getters for resolved preferences in DateTimeFormatter and FixedDecimalFormatter

[sffc]

We need getters for the following:

• Calendar system (should go on DateTimeFormatter)
• Hour cycle (should probably go on DateTimePattern)
• Numbering system (should probably defer to the FixedDecimalFormatter)

[Manishearth]

@sffc and I discussed this a bit.

In general for getting ECMA402 resolved options from ICU4X's APIs, there are three types of things:

1. Things that were fed to the API in the first place, like grouping separator settings
2. Things obtainable from the data resolution pipeline. Resolved locale, resolved numbering system, etc.
3. Weird stuff that needs further computation. Hour cycles.

For type 1, we should just ask ECMA402 implementors to retain any data they wish to. There is no point in us unconditionally retaining such data.

Type 3 is weird and needs to be figured out in a case by case basis.

Type 2 is what we actually need to focus on here. There are a couple of non-mutually-exclusive strategies

Strategy A: Data provider interception

People can write custom data providers that intercept the loads for particular keys and record things like final resolved DataResponse locale, or in case of FixedDecimalFormat the last decimal/digits data attribute loaded. DryDataProvider is designed to help with this.

This is possible today.

Things we can do to make this more pleasant:

• Provide FFI solutions for this
• Provide a way to conveniently use this with baked data, as in Expose provider::Baked as per-formatter Fork providers #5922
• Document techniques here
• Document the order of key loads. For example we would have to guarantee that FixedDecimalFormatter's resolved digits data is always from the last successful load.

Cons:

• Requires custom data providers / annoying over FFI
• Mostly only doable in the unstable world.
• Requires brittle understanding of how the data loading works in each type
• Requires caller to retain this information, they cannot get it on demand

We could potentially design some mid-level abstractions for this.

Strategy B: try_new_get_resolved_options() -> Result<(Foo, FooResolvedOptions)>

We could add a set of constructors that returns Type 2 resolved options on each of these types. So we'd have FixedDecimalFormatter::try_new() and FixedDecimalFormatter::try_new_get_resolved_options() and FixedDecimalFormatter::try_new_get_resolved_options_unstable() and so on.

We'd add a FixedDecimalFormatterResolvedOptions type as well.

Cons:

• Way more constructors
• Requires caller to retain this information, they cannot get it on demand

Strategy C: resolved_options_for(&locale, &provider) -> FooResolvedOptions

We could also encapsulate this work into a separate function that uses DryDataProvider.

This is nicer over FFI.

This would either be only in the unstable or baked world, or would split into a set of three methods for baked/buffer/unstable.

C-for-baked-only does pair well with A to cover all use cases though.

Cons:

• Either only supports baked providers or again explodes the number of constructors
• Requires caller to remember which provider was used at data load time. This may not always be possible if the provider is being appended to. ECMA402 implementors may choose to just retain this information unconditionally, at which point they will be providing data loading twice.
• Also explodes constructors?