Expose resolved calendar and numbering system

[hsivonen]

ECMA-402 Intl.DateTimeFormat.prototype.resolvedOptions exposes the resolved calendar and numbering system, but the existing resolve_components method doesn't indicate these.

For ECMA-402 coverage, there should be an accessor for these.

[sffc]

Calendar is easy. For numbering system, it's an oversight that I think the data doesn't actually name what resolved numbering system you get. For example, here's all we have for arabic:

https://github.com/unicode-org/icu4x/blob/main/provider/datagen/tests/data/json/decimal/symbols%401/ar.json

There's no signal there that this is actually the "arab" numbering system. We should add that to the data file.

[hsivonen]

We should add that to the data file.

Would it be more reliable to inspects what characters digits has and determine the numbering system from the characters?

Or: Why does the data file store the digits instead of storing the numbering system so that digits could be looked up by numbering system? Are there (in practice in CLDR) custom values for digits that don't match any numbering system exactly?

[sffc]

Would it be more reliable to inspects what characters digits has and determine the numbering system from the characters?

Sure, but we'd need to include that mapping somewhere in runtime data.

Or: Why does the data file store the digits instead of storing the numbering system so that digits could be looked up by numbering system? Are there (in practice in CLDR) custom values for digits that don't match any numbering system exactly?

Mainly because the list of digits is tiny enough that it's more efficient to just copy it into the DecimalSymbols data structure, rather than incur an additional runtime lookup to map the numbering system to the digits.

[sffc]

@sffc to write up a design.