Reconsider location for data struct definitions

[sffc]

With #405, it will no longer be necessary to keep all of the data struct definitions in a common crate. Previously, it was required that all data providers have access to the struct definitions when deserializing data. However, with this no longer the case, we should reconsider this design choice.

[sffc]

Last week, we discussed this and decided it is a good idea to distribute the data structs into their individual crates.

One catch I discovered: the InvariantDataProvider should be able to construct instances of all of these structs. Options:

1. Make a separate crate InvariantDataProvider and have it depend on all crates with data struct definitions
2. Allow crates to register structs to a global registry for the purposes of InvariantDataProvider
3. Keep the struct definitions in a common crate

I like option 2, because it is the most generalizable, such as people adding new struct definitions outside of code ICU4X.

[zbraniecki]

I'm strongly in favor of 2

[sffc]

OK. I'm not sure where to start on implementing option 2. Does Rust have static initializers or some other way to register functions to be run at startup? Or some way to globally loop through all implementations of a certain trait?

[zbraniecki]

We could use lazy_static or phf - http://siciarz.net/24-days-rust-static-initialization/

[sffc]

2020-12-17: Global registries are just bad; probably don't use one. Consider other options, like generic functions powering the InvariantDataProvider. @sffc to read the blog post linked above.

[sffc]

When we move the struct definitions, we can also make serde an optional feature on the icu_provider crate.