Migrate data structs to icu_pattern in 2.0

[sffc]

Now that we have icu_pattern, we should migrate more components to use it where possible. Candidates:

1. icu_decimal (related: Reduce stack size of DecimalSymbolsV1 #4437)
2. icu_list
3. Anything sitting around in icu_experimental that hasn't been migrated yet (not a 2.0 blocker)
4. Maybe icu_datetime but that will require more surgery and might not be worth it
5. Others?

CC @robertbastian

[robertbastian]

icu_list has a couple of invariants that are not available on icu_pattern, specifically that {0} and {1} have to appear in that order, and that nothing can precede the {0} (end and middle patterns) or follow the {1} (start and middle patterns). These invariants allow taking substrings of the patterns to be stitched together, instead of creating a massive tree of Writeables, which I think is more efficient.

[sffc]

Nested writeables can usually be composed in such a way that it should be equivalent to a loop when unrolled, but I agree it can be tricky to get to that point.

The list data struct could apply the additional invariants during deserialization.

The main thing we want for 2.0 though is to evaluate the cases and make an educated engineering decision that certain things are too much work / infeasible / lacking in ROI. I'm okay making such a determination for ListFormatter data.

[robertbastian]

The list data struct could apply the additional invariants during deserialization.

Then I'm basically writing a new pattern type. As I already have a pattern type I don't see what the upside would be.

[sffc]

Closing this because all work is tracked elsewhere