Add Hans and Hant scripts; improve Hani sample

[valadaptive]

This is a somewhat hacky fix to allow properly loading fallbacks for Chinese scripts on Windows.

The "Hans" and "Hant" (simplified and traditional Chinese) script identifiers were missing, and "Hani" included a character which is included in Yu Gothic UI, Windows' default Japanese font, which only contains kanji.

This means that selecting a "Hani" (all Han ideographs) fallback would select a Japanese-only font that's missing some ideographs that seem to be used in Chinese.

I do not actually speak Chinese; I found these characters by looking in gaps in Yu Gothic UI's coverage that Microsoft JhengHei UI fills. Someone more familiar with Chinese and/or Japanese could probably do a better job finding sample characters that are used only in Chinese and not Japanese.

We need to put the Chinese-only characters first in the "Hani" sample because of the way the DirectWrite fallback handling works--we call IDWriteFontFallback::MapCharacters repeatedly, advancing the "head" of the string one character at a time, until we get a match. However, the documentation for MapCharacters says that it actually works by returning "the font that should be used to render the first mappedLength characters of the text"--that is, it returns a font that you can use to render the first bit of the string, then you advance and call it again on the next bit, repeat until all characters are mapped. This means that the way we do things, only one character in each sample (with preference given to earlier ones) needs to match in order for a fallback font to be selected.

If things worked more like the fontconfig backend seems to, where there's a whole list of fallback families, this would be fine, but the DirectWrite backend only ever returns one fallback which may not cover all characters in the given sample string. That's a less-hacky longer-term solution.

[xorgy]

I think this is an improvement.
Font selection in han text is difficult, and to get a good result you need to have locale priority information from the environment.
You are correct about fallback; usually you will be fine, but users who encounter mixed text or text with obscure characters will expect fallback to work for individual characters. I receive text with characters that are only found in one font on my system (TW-Kai-Ext-B), and mixed fonts is the expected fallback behavior.

For example, the idiom 歹鬼𤆬頭 includes characters that are available in TW-Kai (standard), but the third character is in TW-Kai-Ext-B; or on GitHub with Chromium on my machine, three of the four characters come from Segoe UI, and one the third one comes from Noto Sans TC.

[raphlinus]

I chatted with @dfrg and he said he was fine with this going in. It's probably something that will need to get reworked at some point, but improving the current state is a good thing. Thanks!