Add documentation on that standalone language codes like "en" are also supported, and not just language-country codes like "en-US".

Brief description of your issue

Directly based on https://github.com/microsoft/winget-pkgs/pull/407968#discussion_r3683888994.

It's safe to say that @Trenly knows more about the codebase factors for this than I do, so I'll mostly quote him. Though a qualified guess of my own on a summary, is that it's a lack of official tests in winget-cli for that kind of scenario (Things that involve 2-letter language codes without countries) that necessitates further test environments for them.

More or less direct quotes, though shortened for focus:

• "(…) - I'm not seeing any code coverage in the CLI repo that ensures the two letter tags resolve correctly"
• "(…) - it's not that I'm worried it won't work. As you correctly pointed out - it does seem to be handled. My concern is that it is NOT tested anywhere in the CLI codebase, which makes the implementation undefined behavior
  Things like -
  • InstallLocaleRequirement: ["en"] - does it pass or silently reject en-US packages?
  • ARP producing "en" as InstalledLocale during an upgrade flow is never exercised
  • Raw GetDistanceOfLanguage("en", "en-US") - the Windows API score is never asserted in any tests"

And keep in mind, it is in fact supported, with the XnSoft.XnShell package in pkgs having become a prominent case of it.

Start by reading the existing winget-cli documentation and tests covering language tags. Check the InstallLocaleRequirement, ARP InstalledLocale, and GetDistanceOfLanguage scenarios named in the issue, including the standalone "en" case. Done means the documentation clearly states that standalone language codes are supported and the relevant behavior is covered or explicitly explained.