Normative: Add more explicit algorithms for lookups

[anba]

Add more explicit steps which should match the results when using ICU4C.

Being more explicit which Unicode extension keys are used is important for implementations like SpiderMonkey, which has to sanitize the locale identifier before passing it to ICU4C. SpiderMonkey allows locale identifier longer than ULOC_FULLNAME_CAPACITY (157 characters), so we have to sanitize the locale identifier before passing it to ICU4C, otherwise ICU4C will reject the locale identifier with U_BUFFER_OVERFLOW_ERROR. (I think this also applies to JSC.) V8 directly calls into ICU4C, so it inherits the ULOC_FULLNAME_CAPACITY restrictions and can't even create Intl.Locale with long locale identifiers.

When to use rg or sd or even fall back to the default locale seems a bit arbitrarily to me, but that's the current ICU4C behaviour, so it's what users will get in browsers. 🤷

a27bd64:

• Use rg and sd Unicode extension keys to lookup the region.
• Use "gregory" resp. "h23" if no calendar or time data is available.

df2d9cc:

• Determine the script subtag using the steps from Add textInfo / script metadata API to determine directionality of locale unicode-org/icu4x#3172 (comment).
• rg and sd Unicode extension keys are ignored.
• Returns "ltr" when no script metadata is available. (This case can happen if the script's metadata uses UNKNOWN for the RTL property or if the script is invalid.)

81e9d12:

• Use %Intl.NumberFormat% to lookup the default numbering system.
• rg and sd Unicode extension keys are ignored.
• Use "latn" if the locale isn't found in the available locales list of %Intl.NumberFormat%.

23d08eb:

• Use %Intl.NumberFormat% to lookup the default numbering system.
• rg and sd Unicode extension keys are ignored.
• Use the default locale (!) if the locale isn't found in the available locales list of %Intl.Collator%.

Applies on top of #91.