Don't enable `icu_provider/alloc` from component crates

[robertbastian]

This makes the DataPayload bigger, and not Send+Sync without the sync feature. We shouldn't enable icu_provider/alloc just to get zerofrom/alloc and yoke/alloc.

[sffc]

The 2.0.x component crates I released rely on icu_provider/alloc implying writeable/alloc and zerovec/alloc. If we do this, then we need to patch-release 2.0.x as well as 2.1.x crates, or else we repeat the same sort of problem as last time.

[robertbastian]

I guess it doesn't actually increase the size unless the compiler can optimize &'static ():

/// The actual cart type (private typedef).
#[cfg(feature = "alloc")]
pub(crate) type CartInner = SelectedRc<Box<[u8]>>;
#[cfg(not(feature = "alloc"))]
pub(crate) type CartInner = &'static ();

It does however makes the struct not Send+Sync when the alloc feature is enabled but the sync feature isn't: https://github.com/unicode-org/icu4x/issues/7208

[Manishearth]

@robertbastian Figured it out: Assuming the serde stuff is undone, the issue is not between component crates; it is for users of ICU4X

If I am a user of icu_casemap and relied on it enabling icu_provider/alloc indirectly (without realizing it), I am broken by this change when I update icu_casemap.

This is probably a minor issue. Questions:

• Does it even make sense to "rely" indirectly on icu_provider/alloc? I think that's the type of thing only cared about by component crates
• Is it easy to accidentally rely on it? I think no.
• Can we consider this a user bug? I think yes, but we should be careful.

I think we lucked out by versioning policy here: all crates which depend on icu_provider are ones where we use ~ deps. So this is probably all fine.

[sffc]

WG notes:

• @sffc The core issue is https://github.com/unicode-org/icu4x/issues/7208
• @robertbastian The cause is that component crates enable icu_provider/alloc which they didn't used to do.
• @hsivonen Seems like a pain point that people depend on Send/Sync being dependent on features.
• @robertbastian We could require the sync feature for Send/Sync in all cases, but that's also a breaking change.
• @Manishearth There are multiple buckets of problems. There are problems for existing users, problems for future users. We need to be careful about moving problems around between buckets.
• @robertbastian Can you explain why the PR breaks things?
• @sffc 2.0 and 2.1 crates rely on icu_provider/alloc in order to get the ZeroVec/Writeable alloc
• @robertbastian But that will still work; icu_provider/alloc still does that.
• @Manishearth There could be external crates relying on that behavior, too. It's an issue for other crates; maybe it isn't between component crates any more.

[sffc]

As long as this change doesn't break 2.0.x and 2.1.x crates, I approve the change to the Cargo.toml files.

We still must figure out what to do with the serde utils.