Add ability to get language prefs for categories

[cjohnson19]

Adds a new lang_category function which accepts the POSIX standard locale category values. Each value is checked in priority order as:

1. LC_ALL
2. LC_xxx
3. LANG

Closes #145

[cjohnson19]

Oh, duh. I would have to implement this for the other OS targets as well if I want to have it be exposed to consumers of the library. It seems like Windows has a similar interface for these If I'm reading the documentation correctly. I'll mark this as a draft and work on adding support there.

[AldaronLau]

@cjohnson19 Thanks for the PR, this is great! Not sure if you're ready for feedback yet, but I think it would be best to change / replace the existing langs() API as part of the 2.0 update (rather than add a new API). I don't think it ever was designed just right from my attempts.

I had in mind something like this:

#[non_exhaustive]
pub struct LanguagePrefs {
    // maybe not `pub`, and have getters returning `impl Iterator<Item = Language>`?
    pub monetary: Vec<Language>,
    pub numeric: Vec<Language>,
    pub time: Vec<Language>,
    pub message: Vec<Language>,
    // ...
}

// Maybe named `lang_prefs` or `localization_info`?
pub fn lang_prefs() -> Result<LanguagePrefs> {
    todo!()
}

For platforms without the lang category support, I think it should set each category to the "main language preferences" (I'm also okay with deferring Windows edit --and other operating systems-- support to a later PR, and using fallback behavior). I'm not fully sure my idea is the design to commit to yet, though - so I'd love to hear if you have other ideas.

I think the lang_category() API you have might not be ideal, because if you wanted to check all the categories, you're now checking the environment variable LC_ALL a bunch of times in a row. It also requires the user to grab all the different kinds of lang categories from the OS manually (going through the new enum), which whoami could just provide. Also, from an API design standpoint, current whoami APIs keep the enums as return values (not used for parameters), which I think it keeps it simple and easy-to-use.

An alternative idea I have is

#[non_exhaustive]
pub enum LocalePreference {
    Any(Language, Country),
    Message(Language, Country),
    Numeric(Language, Country),
    Time(Language, Country),
}

// or
pub struct LocalePreference {
    // would be `Any`, `Message`, `Numeric`, `Time`, etc.
    kind: LocalePreferenceKind,
    language: Language,
    country: Country,
}

pub fn locale() -> Result<impl Iterator<Item = LocalePreference>> {
    todo!()
}

Apologies for not writing all my ideas in the original issue, and keeping it in my head until now. Thoughts?

[cjohnson19]

Apologies for not writing all my ideas in the original issue, and keeping it in my head until now.

No, thank you for the guidance! Your approach makes a lot more sense! Your approach of creating a new structure to return looks nice to me.

When it comes to providing these categories in the language response, should we override categories with the precedence that is defined in POSIX or should we return them literally? For example, if a user's locale setup is:

LC_COLLATE="de_DE.UTF-8"
# ...
LC_ALL="en_US.UTF-8"

Should we return the COLLATE as en_US or de_DE?

My gut tells me we handle the precedence, but I can see how some may find that confusing.