CJK extension J

[eggrobin]

UTC-180-C1 Consensus: Accept 4,300 CJK Unified Ideographs in a new CJK Unified Ideographs Extension J block with code point range U+323B0..U+3347B (block: U+323B0..U+3347F), based on document L2/24-138 (aka WG2 N5254) and Section 07 of document L2/24-165, for Unicode Version 17.0.

[181-C11] Consensus: Accept the proposal to remove U+32E11 (kIRG_TSource = TE-2725) and U+33281 (kIRG_UKSource = UK-20710) from the CJK Unified Ideographs Extension J block, based on UTC discussion of US NB ballot comments on ISO/IEC 10646 7th Edition CD1, for Unicode Version 17.0.

See L2/24-138 Recommendation M71.14. From CJK: L2/24-165 §07. https://github.com/unicode-org/utc-release-management/issues/133

[markusicu]

minus 2: [181-C11] Consensus: Accept the proposal to remove U+32E11 (kIRG_TSource = TE-2725) and U+33281 (kIRG_UKSource = UK-20710) from the CJK Unified Ideographs Extension J block, based on UTC discussion of US NB ballot comments on ISO/IEC 10646 7th Edition CD1, for Unicode Version 17.0.

[eggrobin]

Should be good répertoire-wise, but still draft as it needs Unihan.

[eggrobin]

We have Unihan as one block rather than per-proposal, and I do not want to start doing Unihan surgery to split it. On the other hand, the invariant tests will not be green unless Unihan is consistent with the répertoire. I do not want to merge things into main without invariants passing, since they just caught a mistake here (See https://github.com/unicode-org/unicodetools/pull/883/commits/9a30e593a3569b209a95c60d92b40d7f9edc6c07).

So: I will create a unihan-17 branch in unicode-org, retarget this PR and #884 to it, and then create a PR from unihan-17 to main; this one should be green. @markusicu, does that sound reasonable?

[markusicu]

One way or another, it makes sense to update Unihan all in one PR, because that's how KenL delivers the data files. And I would start with his data files, as before, and adjust other properties and constants to match.