<format>: Add grapheme clusterization support for width computation

[barcharcraz]

• Adds three(ish) new iterators, one for codepoint-by-codepoint unicode decoding (utf-8 or 16), one for grapheme clusterization, and one for counting the width of a string. (The reason the third is needed is that for legacy encodings we'd like to only count the width, we have no need to actually decode them to UTF-32.)
• Uses these in _Measure_string_prefix to count only the first character of each unicode extended grapheme cluster (untailored) as defined in UAX29 and using the Unicode 13 data files (included in tools/unicode_properties_parse). This new processing is only turned on for the "statically UTF-8" case, and not when the system codepage is set to UTF-8, this could be improved in the future, although arguably leads to more consistent behavior.
• _Fmt_codec is adapted to use the new unicode parsing functions, this makes it more robust against malformed (in particular truncated) UTF-8. _Parse_align still gets only the number of code units in the alignment character, so it will copy an entire malformed subsequence to the format specs, not a U+FFFD replacement (this is not tested).
• tests for unicode decoding and clusterization. Clusterization test data is again generated from the unicode data files. Note the no-op _Decode_utf function for char32_t inputs, this is to facilitate testing, but could be removed without too much trouble (after modifying the test generator to encode its output).

Future improvements:

• we could support clusterization for gb18030, especially if set that as the execution charset, doing this would require actually doing unicode decoding for 18030, not decoding it as GBK, which we do now. Also it's not really clear what we should do on invalid data, since sometimes it's impossible to recover from invalid 18030 like it is with UTF-8.
• The decoding function could surely be faster, but has to be able to handle malformed data correctly, and should be optimized for decoding fairly small quantities of text at once (we absolutely could decode in chunks though)
• it's possible we should be using the codecvt facets here to do the conversion, but I'm not sure if those do the maximal invalid subsequence replacement thing, which I'd like to do here.
• it's possible to implement the first set of break rules as a transition table style state-machine, (maybe the others as well, but the table gets much bigger). This is probably a decent idea.
• If we don't do the above then marking branches as hot or cold in the decode function and the break function may be worthwhile, but this would require vtune investigation.

closes: #1945

[StephanTLavavej]

⚠️ Note to self:

1. We'll need MSVC-internal build/setup changes when mirroring this PR.
2. VS TPN.

[strega-nil-ms]

Looks reasonable, just some small nits (and a terrified comment)

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

Casey approved internal mirror MSVC-PR-395673, feedback addressed

[StephanTLavavej]

😻 🎉 🚀