Move fallback algorithms and data structs into components

[robertbastian]

The fallback logic encapsulated in the LocaleFallbacker et al¹ currently lives in icu_provider_adapters. I propose to move it into components (i.e. icu_fallback/icu::fallback) for these reasons:

• It requires data. It is the only code in provider/ that defines data keys
• The functionality of iterating through a fallback chain is independent of providers
• Baked providers only need LocaleFallbacker to perform fallback (using the provider adapter is probably less efficient), and we don't want it to depend on icu_provider_adapters

The icu_provider_adapters crate will depend on icu_fallback to reexport the API for semver, and to drive the fallback adapter. This works because component crates don't depend on icu_provider_adapters.

Footnotes

1. icu_provider_adapters::fallback::{provider::*, LocaleFallbacker, LocaleFallbackConfig, LocaleFallbackerWithConfig, LocaleFallbackIterator}. The only thing that's staying is icu_provider_adapters::fallback::LocaleFallbackProvider, the actual provider adapter. ↩

[robertbastian]

Putting it in icu_locid_transform might give us some synergies.

[sffc]

• @sffc - I'm in agreement about making the fallbacker live in icu_locid_transform in the short term. In the longer term, given that this crate is going to be a core dependency of globaldata, I want to keep it as lightweight as possible.