Use Intl.Locale as the first step of instantiating formatters about proposal-intl-locale

[littledan]

Aside from including unsupported options, resolvedOptions().locale is currently pretty strict about only including the extensions that are in the locale itself, and not things that are specified via the options bag. I wonder if this might come up in practice, e.g.,

let formatter = new Intl.DateTimeFormat("zh", { calendar: "chinese" });
if (formatter.resolvedOptions().locale !== "zh") alert("Please upgrade to a browser supporting Chinese");

This code would "break" if locale switched to being zh-u-ca-chinese, while it currently "works".

So, I'm thinking to try to preserve the current semantics of resolvedOptions().locale (modulo bugs) for formatters (including new formatters) while simultaneously organizing the specification to be based around creating inner Intl.Locale objects (to remove the multiple parallel paths for locale processing).

[littledan]

Oops, that above example doesn't actually apply because calendar as something in the options bag isn't supported yet (see tc39/ecma402#175). There are other extension keys in options which do make it in, like kf, but those differ across browser in their level of support (as the spec explicitly allows) so they may not be so useful.

Aside from how minimal the string is, there's another mismatch: ResolveLocale uses locale data to determine things like the default calendar, and this shows up in resolvedOptions. Presumably we don't want to do this for Intl.Locale by default (though it could be a feature of maximize()). It's looking a bit tricky to refactor the specification code to be one thing in terms of the other while actually reducing duplication.