toLocaleLowerCase/toLocaleUpperCase should better align with the rest of ECMA-402

[gibson042]

String.prototype.{toLocaleLowerCase,toLocaleUpperCase} were introduced in 9ee8940 and first appeared in the second edition of ECMA-402. But toLocaleLowerCase and toLocaleUpperCase have some gratuitous differences from the preexisting String.prototype.localeCompare and Intl.Collator (the former implemented on top of the latter)—specifically,

1. They resolve a locale using only the first element of a locales array, even if it is not supported but later elements are (e.g., on my machine in en-US, "I".toLocaleLowerCase(["tr"]) is the dotless "ı" but "I".toLocaleLowerCase(["zzz", "tr"]) is "i", while new Intl.Collator(["zzz", "tr"], { sensitivity: "variant" }).compare("i", "ı") has the same non-default behavior as new Intl.Collator(["tr"], { sensitivity: "variant" }).compare("i", "ı")).
2. The resolved locale is selected by prefix rather than best fit (although this might not be observable).
3. They don't have an options parameter, which if it did exist would support a "localeMatcher" property for configuring the previous.

The second two points probably don't matter, at least with current locale data. But the first difference would surprise anyone sufficiently familiar with Intl APIs, and results in a worse end-user experience. I'd like to fix it by aligning the String methods with other Intl APIs, specifically fixing at least the first two points by replacing TransformCase's direct use of LookupMatchingLocaleByPrefix(_availableLocales_, _noExtensionsLocale_) (which is accidentally invalid as of f16f3ad and should be something like LookupMatchingLocaleByPrefix(_availableLocales_, « _noExtensionsLocale_ »)) with e.g. ResolveLocale(_availableLocales_, _requestedLocales_, _resolutionOptions_, « », _emptyLocaleData_).[[Locale]] (which would also be a change to using the default locale rather than "und" when the first requested locale is not supported) or ResolveLocale(_availableLocales_, _requestedLocales_, _resolutionOptions_, « », _emptyLocaleData_, *"und"*).[[Locale]] (extending ResolveLocale to support a configurable default in support of preserving the current behavior).

[sffc]

TG2 discussion: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-01-16.md#tolocalelowercasetolocaleuppercase-should-better-align-with-the-rest-of-ecma-402-896