Normative: Update String toLocale{Lower,Upper}Case to ResolveLocale with best-fit matching

[gibson042]

Fixes #896

• Do not ignore locales after the first in the list returned by CanonicalizeLocaleList(locales) (observable via e.g. "I".toLocaleLowerCase(["zzz", "tr"]) === "ı").
• Match against the items of that list by best-fit rather than prefix, aligning with the rest of ECMA-402 (although the difference is not necessarily observable).
• When the list is not empty but no matching locale is found, default to DefaultLocale() rather than "und", aligning with empty-list behavior and with the rest of ECMA-402 (observable via e.g. "I".toLocaleLowerCase("zzz") === "I".toLocaleLowerCase() regardless of default locale, just like new Intl.Collator("zzz", { sensitivity: "variant" }).compare("i", "ı") === new Intl.Collator(undefined, { sensitivity: "variant" }).compare("i", "ı")).

[anba]

• Do not ignore locales after the first in the list returned by CanonicalizeLocaleList(locales) (observable via e.g. "I".toLocaleLowerCase(["zzz", "tr"]) === "ı").

But also "I".toLocaleLowerCase(["en", "tr"]) === "ı", because "en" will generally don't have locale-sensitive case mappings, which means the next locale in the list gets selected.

• Match against the items of that list by best-fit rather than prefix, aligning with the rest of ECMA-402 (although the difference is not necessarily observable).

"best fit" matching isn't supported in browsers. (V8 has "--harmony-intl-best-fit-matcher", but that's not available by default.)

• When the list is not empty but no matching locale is found, default to DefaultLocale() rather than "und", aligning with empty-list behavior and with the rest of ECMA-402 [...]

That means "I".toLocaleLowerCase("und") can now return either "i" or "ı", depending on the user-locale.

[gibson042]

• Do not ignore locales after the first in the list returned by CanonicalizeLocaleList(locales) (observable via e.g. "I".toLocaleLowerCase(["zzz", "tr"]) === "ı").

But also "I".toLocaleLowerCase(["en", "tr"]) === "ı", because "en" will generally don't have locale-sensitive case mappings, which means the next locale in the list gets selected.

Ah yeah, I guess the Available Locales List needs to include more than just locale identifiers with language-sensitive case mappings. Any thoughts on what it should be? Mayble %Intl.Collator%.[[SortLocaleData]]?

• Match against the items of that list by best-fit rather than prefix, aligning with the rest of ECMA-402 (although the difference is not necessarily observable).

"best fit" matching isn't supported in browsers. (V8 has "--harmony-intl-best-fit-matcher", but that's not available by default.)

That's irrelevant, because LookupMatchingLocaleByBestFit is defined to produce results "at least as good as those produced by the LookupMatchingLocaleByPrefix algorithm" (and therefore any implementation is free to just reuse LookupMatchingLocaleByPrefix).

• When the list is not empty but no matching locale is found, default to DefaultLocale() rather than "und", aligning with empty-list behavior and with the rest of ECMA-402 [...]

That means "I".toLocaleLowerCase("und") can now return either "i" or "ı", depending on the user-locale.

I believe that would also be addressed via the Available Locales List provided to ResolveLocale, but regardless should align with other Intl services in general and Intl.Collator in particular. Probably, "und" should just always be considered available, but definitely should not be given special treatment exclusively in TransformCase.