Add CP_UTF8 support to GetConsoleLangId

[lhecker]

The reasons why the console code page has an effect on the default
thread locale on Windows is not noted anywhere. If I had to take a
guess, I'd say it's related to the history of the han unification.

In any case, CP_UTF8 is not a "code page" and so it should not have
an effect on the thread locale either. This issue goes all the way
back to the introduction of CP_UTF8 in XP, over 20 years ago.

Closes MSFT-56188683

Validation Steps Performed

• Switch OS display language to Japanese
• Switch user default codepage to Japanese (932)
• Run the modded OpenConsole
• chcp 65001
• netsh interface ipv4 show interface
  has Japanese table headers ❌

[DHowett]

Wow, this one is intricate for how simple the code looks

[miniksa]

The only question I really have is "what happens to FormatMessage calls inside a client process on the other end when you return this?"

I fully believe that.... 10 years ago... I didn't think through that it would make sense for UTF-8... which had never really been supported in the past... to return the STATUS_NOT_SUPPORTED. But I'm also wondering whether FormatMessage is now gonna be broken and other less enlightened tools are going to have a really bad time.

[lhecker]

I'll of course test this properly before we merge this, but in theory when this returns the unsupported status, the per-thread locale will remain undefined. In that case FormatMessage is documented to use the user locale. So theoretically it should just use Japanese or whatever, as expected, and just how it behaves in non-East-Asian locales.

[zadjii-msft]

I just love¹ functions that have 6 paragraphs of comments spanning a decade to understand just how load bearing they are

Footnotes

1. is love the right word? ↩

[lhecker]

Don't merge this PR yet though. While I do I think it's doing the correct thing, it's not exactly working with netsh yet. (I just started testing it.)

[DHowett]

you asked for this