Fix character class range matching

[hamishknight]

Previously we performed a lexicographic comparison with the bounds of a character class range. However this produced surprising results, and our implementation didn't properly handle case sensitivity.

Update the logic to instead only allow single scalar NFC bounds. The input is then converted to NFC in grapheme semantic mode, and checked against the range. In scalar semantic mode, the input scalar is checked on its own. Additionally, fix the case sensitivity handling such that we check both the lowercase and uppercase version of the input against the range.

Resolves #401
Resolves #395
rdar://96898279

[hamishknight]

Hrm, I thought the macOS CI would be new enough by now

[hamishknight]

So it turns out the macOS CI does have a new enough toolchain, it's just that when testing through swift test with a development toolchain, the OS stdlib is used. This differs from when testing within Xcode where it seems dyld is told to use the toolchain stdlib instead. Seems like it would be nice to figure out a way to get the macOS CI using the toolchain stdlib, but for now let's guard certain tests against older stdlibs.

[hamishknight]

Splitting off the _CharacterClassModel work into #578

[milseman]

We talked about this, and we want to do the following errors. Workaround for 1-2 is to use a scalar escape, which is clearer and more explicit anyways and doesn't have the bug potential (specially since copy-past might normalize to NFC on them, etc)

1. Parse-time: error for any non-NFC literal content (using old stdlib SPI)
2. Parse-time: error for any literal multi-scalar custom character class range bound
3. Run-time compilation: error for any (even escaped) multi-scalar custom character class range bound

[hamishknight]

@swift-ci please test

[Azoy]

This looks great, thank you!

[hamishknight]

@swift-ci please test