Split date skeleton key in two, with datagen

[sffc]

Need to see if this helps with data size

[sffc]

Sizes (all locales, maximal deduplication, for each key):

164K    /tmp/icu4x_both.postcard
96K     /tmp/icu4x_day.postcard
52K     /tmp/icu4x_ext.postcard

So it looks like splitting does make things smaller.

[Manishearth]

we should have more comments explaining what ext is

[sffc]

I did a little experiment to find the most efficient split.

For splitting into 2 keys, we're near the optimum with the split proposed in this PR.

For splitting into 3 keys, we should add a split between YearMonthDay and EraYearMonthDay.

For splitting into 4 keys, we should add a split between Year and EraYear.

It's also possible that reordering the skeleta within the list would yield smaller blocks. I haven't tested this.

[sffc]

Splitting the skeleta each into a separate key makes things the smallest, even with the lookup tables. The lookup tables get smaller when the keys are smaller because there is more deduplication. Even in hybrid mode, the wins on data size are great enough that it looks like it would more than offset the increase in lookup table sizes.

[sffc]

Here's a hypothesis worth testing. I expect that making the keys shared across calendars but unique on components would yield better results than the other way around. Patterns don't differ as much across calendars as display names, but they differ a lot from skeleton to skeleton.

[sffc]

Moving this to draft because I want to compare it with #4779

[Manishearth]

I expect that making the keys shared across calendars but unique on components would yield better results than the other way around.

Wait, really? How would we handle cases where calendars differ, an "extra values" table?

Also won't that deduplicate anyway?

[sffc]

Code archived at https://github.com/sffc/omnicu/tree/archive/neo-skeleta-two-key