There is quite a lot to be done here so this is just a first pass at
number formatting. Decimal and percent formatting are mostly working,
but only for standard and compact notation (engineering and scientific
notation are not implemented here). Currency formatting is parsed, but
there is more work to be done to handle e.g. using symbols instead of
currency codes ("$" instead of "USD"), and putting spaces around the
currency symbol ("USD 2.00" instead of "USD2.00").
Currently, we have NotA and NotAn, to be used dependent on whether the
following word begins with a vowel or not. To avoid this, change the
wording on NotA to be independent of this context.
The keyword accessors all have the same function body in the spec,
except for the Intl.Locale method they invoke. This generates those
properties in the same manner as RegExp.prototype.
Intl.Locale.prototype.calendar
Intl.Locale.prototype.caseFirst
Intl.Locale.prototype.collation
Intl.Locale.prototype.hourCycle
Intl.Locale.prototype.numberingSystem
The exception is Intl.Locale.prototype.numeric, which will be defined
separately because it is a boolean value.
This isn't particularly testable yet without the Intl.Locale constructor
but having this defined will make testing the constructor possible. So
more specific tests for this prototype will come later.
In the IsStructurallyValidLanguageTag AO, we of course cannot assume the
variants are canonicalized to lower-case yet, because canonicalization
hasn't happened yet.
ErrorType::IntlInvalidCode has almost exactly the same message as
ErrorType::OptionIsNotValidValue. Remove it, as all uses of the former
are semantically interchangeable with the latter.
Note that only option type=region is really implemented. Other types
will resort to the fallback option. This prototype method will be able
to implement other type options once LibUnicode supports more.
There is notably FIXME notations in this commit regarding Unicode locale
extensions. We are not parsing extensions (or private use extensions) at
all yet.
