Discuss: Should LocalePreferences have public fields

[zbraniecki]

Issue: Not a fan of this having public fields. But that can be fixed after the PR lands

Originally posted by @sffc in #5729 (comment)

[sffc]

Duplicate of #5786

[sffc]

Actually let's keep this issue open so we have one discussion per thread.

[sffc]

So the main problem here is that DataLocale lives in icu_provider and it needs to be efficiently constructed from this type that lives in icu_locale_core.

Can we just move DataLocale into icu_locale_core?

My personal opinion is that I think it is silly and over-designed to try and keep the types exported from core crates as minimal as possible and put specialized types into other crates. I prefer "useful" core crates: ones that export types that its dependents need.

[sffc]

Conclusion:

• LocalePreferences gets private fields
• It has conversion impls from &LanguageIdentifier and &Locale
• DataLocale moves to icu_locale_core::DataLocale
• LocalePreferences has two conversion functions into a DataLocale: to_data_locale_language_priority(self), to_data_locale_region_priority(self)
• DataLocale gets private fields
• Add a helper function in icu_provider::marker to call the right DataLocale constructor based on the marker
• Also change the associated trait function DataMarker::bind to be a helper function in that module
• Take a birds-eye view of preferences after it is landed in all the crates
  • open question: should preferences be Copy

LGTM: @Manishearth @robertbastian @sffc @zbraniecki