Be more consistent about options modules

[sffc]

icu_datetime has an options module which is public.

icu_collator and icu_segmenter have a private options module and re-export the things from the top level.

Haven't done an audit of the other crates.

Should we be more consistent?

@zbraniecki @Manishearth

[Manishearth]

I'm not overly bothered by this, individual crate organization in this sense has to do with how cluttered the crate is. If the crate has a single main type, it's not too bad to clutter the root module. If it has many different types it might want an options module.

Overall options are required to be specified in a lot of places so having short imports is nice. Perhaps we should default to hoisting these types to the top unless the crate has a lot of modules and types, in which case we put them wherever it makes sense.

I think "options types are in a module in some crates and not in others" is low-confusion: I don't think people will be copy pasting code for working with different ICU4X components, they're already quite different.