Non-fallback mode with extension keywords

[sffc]

We should write down what clients should do with extension keywords in non-fallback mode (preresolved or hybrid).

Currently, if a user requests ar-EG-u-nu-latn from the FixedDecimalFormatter, it will succeed. However, if they request en-US-u-nu-latn, it will fail, because there is no explicit data for that extension. Likewise, ar-EG-u-xx-yyyy will fail if xx is an irrelevant extension keyword from the constructor.

Also, if constructing a DateTimeFormatter, ar-EG-u-nu-latn will fail, even though FixedDecimalFormatter is one of the component parts. (We should probably add DTF::try_new_with_fixed_decimal_formatter to work around this)

We could:

1. Document this behavior and leave it as-is
2. Make constructors for extension-sensitive keys have some extra logic for extension handling, outside of data provider
3. Make all constructors have extra logic for extension handling, outside of data provider

I lean toward (1).

[sffc]

@sffc to propose a design here and also how this relates to aux keys.

[sffc]

Related: #3867

[robertbastian]

Per decision in #3867, preresolved datagen should be able to preresolve the correct locales.

[robertbastian]

Probably solved by https://github.com/unicode-org/icu4x/issues/3867

[sffc]

Actually icu_preferences is the thing that should resolve this particular issue. I will move it to the 2.0 milestone.