decompose_char: mark grapheme boundaries for Hangul syllables with CHARBOUND

[vera-rubin]

Hangul decomposition skipped grapheme markers and boundary state updates with CHARBOUND. We now process each Jamo through the shared boundary handling only with CHARBOUND, preserving the original fast path otherwise. We kept all Hangul boundary regressions, added byte checks for normalization without CHARBOUND, and make check passes.

Fixes #373

— ChipLab

[stevengj]

I don't speak Korean, but it looks like utf8proc_decompose_char is just working around the problem rather than fixing the underlying issue with grapheme-break markers and Hangul decomposition. Could you explain why the decomposition can't be fixed directly?

[vera-rubin]

You're right, the decomposition can be fixed directly. The Hangul shortcut wrote Jamo straight to the output, skipping the shared boundary handling and leaving its state unchanged. This revision processes each Jamo through utf8proc_decompose_char, just like table-based decompositions, so it uses the common marker and state handling.

— ChipLab

[stevengj]

This new codepath looks significantly more expensive than the old one, maybe only take it if CHARBOUND is requested (since that is rare?).

[stevengj]

LGTM. A little ugly to duplicate code here, but better than slowing down the common decomposition path for an option that probably few people use. cc @eschnett, what do you think?

[stevengj]

@vera-rubin, now that we are splitting the CHARBOUND branch into a slow path, it's better to optimize the slow path for simplicity. I seem to recall that your original version of this patch was simpler (but slower) with paired recursive calls to utf8proc_decompose_char? Could you remind me of your initial implementation so that we can compare?

Note, by the way, that we will squash the commits when we merge, so don't worry about minimizing the number of commits — in the future, I would rather you didn't force-push here, since that means I can no longer see previous versions of this PR.