Reinvent icu_pattern with support for multiple backends

[sffc]

After experimenting with this for some time, it's clear that there is not a single storage solution that works optimally for every use case. I have therefore proceeded to make Pattern generic over its backend. This leads to cleaner, more flexible code.

In this initial PR, I added support for a straightforward and efficient backend SinglePlaceholder. I will follow up with additional backends in future PRs.

Replaces #4579

[sffc]

The data model in this PR: https://icu4x-pr-artifacts.storage.googleapis.com/gha/519c3b32fda1a3c045e00f225da3b8cc6f65dfcc/rustdoc/icu_pattern/struct.NumericPlaceholderPattern.html#pattern-string-encoding-details

[sffc]

Some notes from diving deeper into this with @robertbastian @Manishearth:

• Reminder that placeholders could appear in either order (as we had previously discovered) so some sorting needs to take place
• Placeholders could also appear adjacent to each other; need to handle patterns such as "{1}{0}"
• If we use a UTF-8 varint encoding for the placeholder offsets, limiting the length to 128 means that we can be forward-compatible when changing between a varint and non-varint encoding
• @sffc and @Manishearth suggested some tweaks to the model to handle these cases
• The first model in Add new version of icu_pattern crate #4579 is simpler and more straightforward and probably efficient for short strings, but frontloading the offsets is likely more efficient for long strings
• Since deserialization needs to read the whole string to check for UTF-8, there shouldn't be a significant difference in validation speed between the models; the first model could have a more expensive validation in debug mode

placeholder 1 at index 10
placeholder 2 at index 5
(7, 5), some string
(7,5) 01234{1}56{0}789

[(usize,usize);N]
[(7,0),(5,1)] -> [(5,1),(7,0)]

[(usize, &dyn Writeable)]

"AA{1}{0}BB"

(p1, i2) (p0, i2)

p1 p2
(i2, 2ème), (i2, 1ère)

(0x21, 0x20) "AABB"
[(2,1,0),(2,0,1)]

VZV<str>
VZV<placeholderlist>

[sffc]

The conflict is from 17f2cb0. Accepting mine.

[robertbastian]

Ah I see.

[zbraniecki]

lgtm! Thanks for picking it up!