In existing browser implementations, navigator.languages seems
to expose the basics of a locale--language, possibly region and
script. However, there are additional locale-related settings
which are taken as parameters by ECMA 402 and which fit into
BCP 47 language tags.

It is possible that just changing the value of navigator.languages
could break existing sites. For example, localizations which
are selected based on the exact value of navigator.language would
find an unknwon language if a Unicode extension tag is appended.

For this reason, rather than attempting to expose those options
via BCP 47 Unicode extension tags, this patch adds a navigator.locales
property. navigator.locales is a FrozenArray of Intl.Locale objects.
Intl.Locale is a new proposal in TC39 which makes it easier to
parse and manipulate language tags.

This PR is just intended to start a conversation. There are a few open questions:

• Adding an API to more OS settings adds fingerprinting concerns. However, the folks I've talked with in Chrome and Mozilla so far seem OK with this particular addition.
• I'm not sure how good quality the OS APIs are to get at this data, whether it's a good idea to be calling out to them. At least, putting the calls here, in navigator.locales, rather than saying that the core of Intl defaults to those values, makes it a bit factored out.
• @zbraniecki expressed interest in exposing things like default currency, however, @jshin expressed hesitation both in making this available to language tags (since what does a locale's currency mean--it's not reasonable to format a number you already have with the locale's currency) and to using the OS API for it.
• We could add navigator.locale for ergonomics, though there's not much point when you can use navigator.locales[0].
• Not all user settings will show up cleanly in language tags. For example, some operating systems let users select date formats, but this can't be expressed in a language tag beyond choosing a locale which happens to have that format (but then this locale would also be used for text translation).
• Rather than exposing Intl.Locale objects, we could just expose the strings. Intl.Locale objects might be nicer, though, as you can read properties off of them, such as navigator.locales[0].language to get the main language. A downside is that this feature is blocked on Intl.Locale making it through TC39.

I'd be interested in any feedback you would have.