Exposing normalisation data to external consumers

In https://github.com/linebender/parley/pull/452#issuecomment-3522030972, we identified that it might be useful for consumers of HarfRust to have access to the normalization data to prevent storing duplicate table data in binaries.

Per @dfrg's comment, as a consumer of HarfRust, Parley also wants to match HarfRust so using a single source of truth is beneficial to maintain consistency between shaping and other stages of the text pipeline.

The options of implementation vary:

- Simply expose `normalize_nfc` / `normalize_nfd` functions from `unicode.rs`
- Expose the tables themselves and push consumers to write their own `normalize_nfc` / `normalize_nfd` functions using the data
- Split out the data into its own crate, ask consumers to pass in a trait that implements what HarfRust requires while supporting a `baked` or similar feature flag
- ...

I think the most important question I have is whether there's appetite for this sort of change.

There are other opportunities of deduplication like potentially the [`CharExt`](https://github.com/harfbuzz/harfrust/blob/f739afe3ea3aad71943ed50602726a9c9fc22eee/src/hb/unicode.rs#L369) but I think it might be best to start the dialogue with normalization data?

Start with the discussion in PR #452 and inspect src/hb/unicode.rs, especially normalize_nfc, normalize_nfd, and the normalization data. Compare the listed options for exposing functions, tables, or a separate crate, and review the CharExt deduplication opportunity. Done means the maintainers agree on a concrete API and implementation direction.

Written by the indexing model from the issue text.