UTF-8 support in Windows API

[ysbaddaden]

Extracted from #14670 (comment)

@stakach said:

Worth noting that Windows supports UTF8 now and encourages use of those APIs
https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

As explained on the above link, the trick is to use the ANSI variant (-A) of the Windows API using the UTF-8 codepage, instead of the Unicode variant (-W) that expects UTF-16. This is supported since Windows 10 v1903, and involves some app manifest shenanigan to change the ActiveCodePage (ACP) of the application to UTF-8. Older Windows releases won't have the guarantee that the ACP is indeed UTF-8.

Pros: Crystal using UTF-8 internally, and it would simplify the integration with the Windows API, and maybe be a bit faster (no more UTF-8 <-> UTF-16 transformations in Crystal).

Cons: GDI applications still don't support UTF-8 and a global beta setting must be enabled by the user to enable UTF-8 localization on their computer.

[straight-shoota]

One thing to note is that while Windows 10 v1903 isn't the most recent release, we're currently supporting older versions of Windows as well.
I think Windows 8 is the oldest supported version with default configuration. It goes down to Windows 7, but only with a compile time flag.

At the moment, I don't think we could drop wide string APIs entirely. There might be different paths on how we can keep support for older versions (e.g via flag for opt-in, or opt-out). Might also be possible to compile both variants and decide at runtime dependning on OS version. Since both A and W variants of the APIs are always available, there should be no issue linking both of them.