Create TypedNeoDateTimeFormatter and DateTimePattern types

[sffc]

Part of #3347
Depends on #4496
Depends on #4497

[sffc]

Background: the current DateTimeFormatter is over 6000 bytes. I've demonstrated in this PR that NeoDateTimeFormatter is around 700 bytes, which is a huge improvement, but we want to see if we can get it even smaller.

[sffc]

Review tips:

It should be easier to review this all at once. Commit-by-commit may result in your reviewing code that I subsequently refactored or deleted.

Most of this PR is plumbing. I tried to pull off the interesting parts as I was writing it. There are two more PRs, #4496 and #4497, that are currently open with two small but slightly more interesting bits of code.

This PR adds the following public types:

1. icu_datetime::neo_pattern::DateTimePattern, a public wrapper around icu_datetime::pattern::runtime::Pattern, with a more restricted API surface sufficient to be used in icu_datetime::TypedDateTimeNames (which is already landed)
2. icu_datetime::neo::TypedNeoDateFormatter, which supports formatting with date lengths and uses all neo data
3. icu_datetime::neo::TypedNeoTimeFormatter, which supports formatting with time lengths and uses all neo data
4. icu_datetime::neo::TypedNeoDateTimeFormatter, which supports formatting with date and time lengths and uses all neo data

The code in src/neo.rs and src/neo_pattern.rs is intended to be as thin as reasonably possible, with all business logic living in other modules such as the new src/raw/neo.rs. The code in src/neo.rs is mostly data provider marshaling; by the time you get into src/raw/neo.rs the data provider types are normalized for you.

I introduced a new "external loader" design pattern in src/external_loaders.rs in order to plumb into the correct constructors of types in dependency crates, such as FixedDecimalFormatter and WeekCalculator. I think I managed to get this to be fairly clean and I even have a macro to generate some of the boilerplate.

This implements part of the fix for #4340, but I didn't fix the whole thing in an effort to not scope creep this PR.

[dpulls]

🎉 All dependencies have been resolved !

[Manishearth]

praise: good on keeping these traits only in the bounds of a single method rather than having them spread everywhere (and causing monomorphized code size issues)

[sffc]

Hmm, with AnyCalendar <YearMarker, MonthMarker> are not known until runtime and I don't really want to include more than 1 copy of this function (i.e. through an enum switch). Maybe we can move those over to the external loader architecture so that the enum switch is isolated to the load function. Let's figure that out when I implement the AnyCalendar version of neo formatter.

[Manishearth]

Yep.

[Manishearth]

observation: must stay private, we may need to be able to load RBNF in the long run

in the medium term we will probably hardcode a FixedDecimalFormatter | CustomFormat where the CustomFormat is a simple enum with code attached.

[Manishearth]

nit (nb, followup): roughly document thr format or link to UTS 35.