Use ICU4X built-in data

[robertbastian]

The data that is currently being generated in parley_data is the same data that ICU4X ships with. However, using try_new_unstable constructors with custom data providers can be less efficient than enabling the compiled_data feature, as these constructors do runtime lookups and branching, whereas most compiled_data constructors are const.

Benchmarks look neutral:

Default Style - arabic 20 characters               [   9.9 us ...   9.7 us ]      -1.46%*
Default Style - latin 20 characters                [   4.5 us ...   4.3 us ]      -4.27%*
Default Style - japanese 20 characters             [   9.1 us ...   8.9 us ]      -2.30%*
Default Style - arabic 1 paragraph                 [  55.5 us ...  55.6 us ]      +0.13%
Default Style - latin 1 paragraph                  [  18.2 us ...  17.9 us ]      -1.49%*
Default Style - japanese 1 paragraph               [  76.8 us ...  76.9 us ]      +0.16%
Default Style - arabic 4 paragraph                 [ 234.0 us ... 235.1 us ]      +0.48%
Default Style - latin 4 paragraph                  [  69.0 us ...  68.2 us ]      -1.05%*
Default Style - japanese 4 paragraph               [ 131.9 us ... 136.0 us ]      +3.11%
Styled - arabic 20 characters                      [  11.3 us ...  11.3 us ]      -0.43%
Styled - latin 20 characters                       [   6.3 us ...   6.3 us ]      -0.99%
Styled - japanese 20 characters                    [   9.9 us ...   9.7 us ]      -1.80%*
Styled - arabic 1 paragraph                        [  59.4 us ...  58.5 us ]      -1.40%
Styled - latin 1 paragraph                         [  23.7 us ...  23.3 us ]      -1.82%*
Styled - japanese 1 paragraph                      [  86.6 us ...  87.5 us ]      +1.05%*
Styled - arabic 4 paragraph                        [ 251.7 us ... 252.5 us ]      +0.32%
Styled - latin 4 paragraph                         [  90.4 us ...  89.1 us ]      -1.45%*
Styled - japanese 4 paragraph                      [ 123.7 us ... 124.0 us ]      +0.24%

[taj-p]

I like how much simpler this PR makes Parley and Parley Data, but I worry about how it impacts future work, which you may be able to provide expertise in guiding.

Removing the compartmentalisation provided by AnalysisDataSources would make it harder for us to enable a BYO data mechanism IIUC. In the short term, we want to enable support for complex scripts (and for consumers to pass that data in).

For context, we want to enable a workflow such that, on the web, we can ship the binary separately from ICU data to clients. This enables us to evolve a binary (which is more volatile than ICU data) without the consumer needing to download the same ICU data each binary version.

Separately, this enables a more "pay for what you use" approach with the application layer deciding what ICU data may be provided for a given application state (which may evolve during a client's session).

[taj-p]

For reference, this was the original idea

[robertbastian]

I've reverted the changes to AnalysisDataSources

[robertbastian]

For context, we want to enable a workflow such that, on the web, we can ship the binary separately from ICU data to clients. This enables us to evolve a binary (which is more volatile than ICU data) without the consumer needing to download the same ICU data each binary version.

Your current architecture of using compiled data does not allow for that. Changing to serde data for low level functionality like normalization and properties is not something that we recommend.

None of this data is particularly big. Once we get into complex segmentation data, that strategy makes more sense, but not for the data that this PR changes.

[taj-p]

Changing to serde data for low level functionality like normalization and properties is not something that we recommend.

I was hoping it could be blob based.

None of this data is particularly big.

I think this is relative. The unicode data stored in Parley represents 6% of my binary quota currently 😅 . We might be able to use lazy module instantiation in Wasm to get around that, but it will become an area of optimisation - but, certainly, in the future (and not in the near term!)

[taj-p]

Looks like this change reduces the size of the Vello Editor example from 9.7 MB to 9.57 MB 🎉

[taj-p]

LGTM 🎉

[taj-p]

Changing to serde data for low level functionality like normalization and properties is not something that we recommend.

I was hoping it could be blob based.

None of this data is particularly big.

I think this is relative. The unicode data stored in Parley represents 6% of my binary quota currently 😅 . We might be able to use lazy module instantiation in Wasm to get around that, but it will become an area of optimisation - but, certainly, in the future (and not in the near term!)

[taj-p]

Thank you @robertbastian for the contribution!! This simplifies parley_data a lot and improved our binary size 🙌 🙏 🎉