Handling of horizontal fallbacks

[zbraniecki]

While working on the data for DateTimeFormat, we started touching on the topic of fallbacks for missing data fields. Examples from the realm of 0.1 are:

• If the user asks for short width month name in cs locale, we don't have it: https://github.com/unicode-cldr/cldr-dates-modern/blob/master/main/cs/ca-gregorian.json#L14
• If the stand_alone context for weekday names is the same as format, do we want to return both like CLDR-JSON does for en - https://github.com/unicode-cldr/cldr-dates-modern/blob/master/main/en/ca-gregorian.json#L13
• is it possible that there is no style for date style long - https://github.com/unicode-cldr/cldr-dates-modern/blob/master/main/so/ca-gregorian.json#L277 ?

The two drives that are extremes are:

• We want to make ICU4X DataProvider easy to use. Handling fallbacking in data provider means user doesn't have to worry about missing data and fallback decisions.
• We want to make ICU4X DataProvider flexible. Being opaque about missing data means that user has no flexibility in choosing how to handle fallbacks (do we always want to fallback from short to long if its missing? Maybe in some scenario user will want to fallback differently?

If we go with fallback in the provider, we're likely going to have to add ability to get data without the fallback. If we go with fallback in hands of consumer, we will need to help consumers know how to fallback and there's going to be a number of repetitive pieces of fallbacking in consumers.

Finally, expanding all data in provider means more data to carry over the wire. A good example is the second one - for locales where stand_alone matches format contexts, we could just carry over format and set stand_alone to null and the consumer then can say "if there is stand_alone, use it, if not, fallback on format".
But if we expand all fallbacks in Provider, we'll have to for all locales carry duplicated data so that user can infallibly take stand_alone.

I believe that, as in most cases, we'll be looking for the "third path" somewhere between those two extremes, and we'll need to resolve it on per-case bases, but I think that encoding in wiki (https://github.com/unicode-org/icu4x/wiki/Hooking-up-a-DataProvider) or docs some guidelines on how to generally make decisions on what is going to be expanded in Provider vs. in consumer, is in our best interest, so let's discuss it!

[zbraniecki]

For DateTime 0.1 needs I'm planning to keep Option on:

• context stand_alone since for many locales it is the same as format and storing duplicated data would be unnecessary
• WidthsV1, since not all locales have all widths.

[mihnita]

short width month name
There is no such thing, even for English.
We have wide ("December") abbreviated ("Dec") and narrow ("D")

Does not change the need to address it. Just making sure the description / examples are accurate.

[mihnita]

Shared https://docs.google.com/document/d/19iJb3NSmy0frue3zBmHMibTg2PCgkRCRKNnqQhMfy4Y/
Will convert to .md after the first "weaves" of comments, if that's OK with you?
(but if you want it "right now", I can also do that)