Informal icu_calendar rereview

[Manishearth]

We changed a bunch of icu_calendar for 2.0, and still have some changes planned (#4889)

Now is a good time to have another look at the API shape and do any necessary cleanups.

[Manishearth]

Thoughts:

• Should the individual calendar modules all be organized under icu_calendar::calendars::*? They feel cluttered right now. We could reexport individual calendars into this module.
• WeekCalculator could do with more docs
• We're probably getting rid of DateTime, IsoHour, IsoMinute, IsoSecond, NanoSecond
• We should change MonthInfo to use a FormattableEra code that can be numeric rather than an era code.
• All the try_new_foo_date functions should have uniform APIs and say with_calendar if they're with a calendar

[Manishearth]

@sffc thoughts on the first bullet point?

[sffc]

Hmm, the word "calendar" is already in the crate name, but I agree it would be nice to put the calendars in their own namespace separate from Date and other types/traits.

Maybe icu_calendar::cal::Buddhist? (better than icu_calendar::buddhist::Buddhist)

[sffc]

We're probably getting rid of DateTime, IsoHour, IsoMinute, IsoSecond, NanoSecond

We can get rid of DateTime, but we need Time, IsoHour, ... somewhere because icu_datetime uses them

[Manishearth]

icu_calendar::cal::{Buddhist, etc} works for me.

I will also have the individual calendar modules live there, because the BuddhistDateInner (etc) types need to live somewhere

[sffc]

Thought: icu_calendar::cal::Buddhist and icu_calendar::cal::scaffolding::BuddhistDateInner (as exports only; actual types live in a file named buddhist.rs)

[Manishearth]

scaffolding wfm.

I think any_calendar should live at the top level though, as it does now.

[sffc]

I named it scaffold in #5690 since the style guide is to omit suffixes