Add support for more subtags

[ryzokuken]

Currently, a number of Unicode extension keywords are supported, including nu for numbering systems, ca for calendaring systems, hc for hour cycles, etc.

This issue tracks all the BCP-47 subtags added by Unicode that we do not yet support. Feel free to add to the list below this:

1. rg (Region override): see Region Override Support #370.
2. fw (First day of the week): see First day of the week -- Intl.getCalendarInfo() #6.

[FrankYFTang]

I think we need to have a high level guideline about what should be considered and what should not be.

Currently, ECMA402 is very specific of the following are NOT allowed

and the keys "kb", "kh", "kk", "kr", and "vt" are not allowed in this version of the Internationalization API.
"the keys "kb", "kh", "kk", "kr", and "vt" are not allowed in this version of the Internationalization API. "

[ryzokuken]

@FrankYFTang absolutely! Should we put this on the agenda for the next monthly meeting? I was alluding to the same thing in my review to #581.

[FrankYFTang]

also, another two are "cf" and "ss"
I do not believe "cf" should be specified in extension because "cu" is already not.
https://tc39.es/ecma402/#sec-intl.numberformat-internal-slots
"Unicode Technical Standard 35 describes two locale extension keys that are relevant to number formatting: "cu" for currency and "nu" for numbering system. Intl.NumberFormat, however, requires that the currency of a currency format is specified through the currency property in the options objects."

so I filed PR for adding "cf" in the same way as "cu" in #581

Another is "ss" I filed tc39/proposal-intl-segmenter#142
I think that is a "feature request" for Intl.Segmenter (but I rather we deal with that post Stage 4 merge into ECMA402) since there are no way to control that in options right now . ( @gibson042 ) ICU did that not via an API but via locale too - (see case UBRK_SENTENCE of BreakIterator::makeInstance in common/brkiter.cpp and comments in common/unicode/ubrk.h ) so maybe we should also accept "ss" in extension after we add an option to support that post merging Stage 4 of Intl.Segmenter to ECMA402. I think it is not a good idea to change the current spec of Intl.Segmenter. Maybe a Intl.Segmenter v2 to improve it.

[ryzokuken]

@FrankYFTang agreed on the segmenter. I generally feel that we should prefer subtags over options (since they can be best included in Intl.Locale and passed around in the BCP 47 string) but we can talk about that in greater detail.

[zbraniecki]

Is that a dupe of #105 ?

[sffc]

I think #105 is about filling in the set between the locale and the options bags, whereas this issue is about adding support for new ones.