osd/strconv.cpp: Support UTF-8 Windows ANSI code page.

[invertego]

• Defer to MAME's built-in UTF-8 decoding because MultiByteToWideChar needs the length of the code unit and once that's been determined it's convenient do the rest of the conversion and sidestep the complication of UTF-16 (surrogate pairs).
• Remove the FIXME about other variable length encodings such as GB18030. With the sole exception of UTF-8, only single- and double-character encodings are supported as the active ANSI code page. Other code pages are only usable in conversion functions and not relevant here. Source: [MS-UCODEREF]: Supported Codepage in Windows | Microsoft Learn.
• Remove the FIXME about surrogate pairs because these only arise in the context of Unicode inputs not representable as a single UTF-16 code unit, and as mentioned above UTF-8 (the only selectable Unicode ANSI code page) is now handled directly in MAME code.

[cuavas]

Character-at-a-time conversion will still behave badly with nominal single-byte encodings that use combining characters like Windows-1258 because newer versions of Windows attempt to get clever when converting text runs, e.g. F5 D2 will be converted to a single UTF-16 code unit U+1EDF, but if you naïvely attempt to convert one character at a time, you’ll get the sequence U+01A1 U+0309. The function is fundamentally unsound in concept.

[invertego]

I can't reproduce that behavior with your example on Win11 23H2. If I process both bytes together in a single call, I still get two wchars out.

WCHAR wide[16];
int len = MultiByteToWideChar(1258, 0, "\xF5\xD2", 2, wide, 16);
for (int i = 0; i < len; i++)
	printf("%04X ", wide[i]);

Prints 01A1 0309

That said, this PR only impacts systems with a UTF-8 active code page while avoiding the vagaries of Win32 API.