Consider exposing `langid` on `Locale`

[zbraniecki]

Currently, the Locale API provides the same API as LanguageIdentifier it handles. Methods like get_language, set_language etc.

In theory, we could instead expose the langid field of Locale and let people play with it:

let loc: Locale = "en-US-u-hc-h12".parse().unwrap();
loc.langid.get_language();

And then if they have a mut hold over it, they could replace the whole langid field with a new LanguageIdentifier.

Since there's no situation in which a change to langid value of the Locale affects the ExtensionMap, I believe that such change would be valid.

The question is if

let loc: Locale = "en-US-u-hc-h12".parse().unwrap();
loc.langid.get_language();
loc.langid.get_script();
...

is a more "rusty" API than:

let loc: Locale = "en-US-u-hc-h12".parse().unwrap();
loc.get_language();
loc.get_script();
...

@Manishearth - can you advise?

[zbraniecki]

I got a confirmation from @Manishearth that it makes sense in this case to:

a) expose langid field on Locale
b) keep the convenience methods like get_language/set_language/clear_language matching the ones on LanguageIdentifier.