[yhirose]

Replaces the four code-point-indexed case tables (_simple_case_mappings, _special_case_mappings, _special_case_mappings_default, _case_foldings) with block tables instead of the sorted arrays + std::lower_bound that master switched to. _normalization_composition stays a sorted array since its key is a code point pair, not a single code point, so it can't be block-tabled the same way; a spot check found no measurable difference there.

Motivation

Each of these four tables is looked up once per character, so std::lower_bound shows up directly in to_uppercase(), to_case_fold(), and friends. A block table keeps the static-data benefit master's commit was going for (no map construction at start-up) and is faster than binary search.

Layout

Same shape master already uses for every other property table: a uint16_t index per code point through a block table, plus a flat value array. Row 0 of the value array is a "no entry" sentinel, so the index doubles as the found/not-found flag.

_special_case_mappings has several code points with more than one entry (full_case_mapping() walks them in SpecialCasing.txt order and applies the first whose language/context condition matches), so it's grouped as {offset, count} into a flat SpecialCasing array, the same shape as the existing script extension tables, keyed by code point through a block table. _special_case_mappings_default and _case_foldings have one entry per code point, so they follow _simple_case_mappings's shape directly.

_find_code_point() and the SpecialCaseMapping/CaseFoldingEntry wrapper structs it operated on are no longer used by anything and are removed.

Measurements

Apple M-series, Release -O2, clang, 20 iterations, median of 3 runs:

	master (sorted array)	this PR (block table)
to_uppercase(), ASCII, 500k chars	319.5 ms	52.6 ms
to_uppercase(), mixed scripts, 500k chars	306.2 ms	51.7 ms
to_case_fold(), ASCII, 500k chars	149.1 ms	32.4 ms
to_case_fold(), mixed scripts, 500k chars	178.5 ms	34.3 ms
to_nfc() (unaffected, sorted array kept)	4390.8 ms	4363.8 ms

Isolating just the two special-casing searches accounted for about 75% of to_uppercase()'s time on master despite _special_case_mappings/_special_case_mappings_default having only 16 and 103 entries respectively; a handful of dependent loads per character adds up.

Static data: startup allocations stay at 2933 (unchanged from master, since master already removed the map construction). Test binary is about 17 KB larger than master's sorted-array version, in exchange for the above.

Correctness

Exhaustive differential test against the pre-sorted-array commit (bfdd356, the unordered_map/unordered_multimap version): simple_case_mapping(), simple_case_folding(), is_script(), and full_case_mapping() (upper/lower/title/fold, across 6 locales and 7 surrounding contexts exercising every SpecialCasingContext condition) return identical results for all 1114112 code points. Full test suite passes (770963 assertions in 59 test cases), clean with -Wall -Wextra -Werror on clang.

Changes to generateTable()

Two additions, both defaulting to the previous behaviour so every other generated table comes out byte for byte identical:

• an optional blockSize override. findBestBlockSize() hardcodes an 8-byte item size, so it picks 64 for a uint16_t index table where 256 is smaller.
• tables that do not span the whole code point space are padded to a whole number of blocks, and get_value() gets a bounds check against the table length instead of 0x10FFFF.

While looking at this I also noticed that findDataSize() ignores the cost of the _blocks[] pointer array, so findBestBlockSize() systematically picks blocks that are too small for the existing tables as well. That's unrelated to case mapping and left out of this PR.

[samhocevar]

Yes, leveraging generateTable looks like a much better approach. Any improvements in that function will benefit the whole library.