Add navigator.locales to expose additional locale details

[littledan]

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.

[domenic]

Is there a repository for Intl.Locale? My thoughts so far are mostly about that primitive, e.g. I am confused by its scope and whether we really want a locale or some kind of "culture settings" like .NET has. The latter would allow us to get customized date formats etc. As someone using en-US who sets their date format to YYYY-MM-DD, time format to HH:mm:ss, and temperature to Celsius, I am not very well served by most locale defaults, and I'd rather solve this problem once on the web, instead of solving it once for the 80% case and then again for the 20% case.

By switching over to the actual diff, I found the repository. I will take this line of questioning there: tc39/proposal-intl-locale#3

[littledan]

Talking with the W3C I18N WG, there are some concerns with using the Locale as the means of exposing all of these settings, as opposed to some sort of separate settings object. Separately, @jungshik expressed some concern about how/whether we should get these OS settings. Until we resolve these issues, this PR won't be able to move ahead. Closing for now.