OPTION B: Add format_unchecked functions to DateTimeFormatter via DateTimeInputUnchecked

[sffc]

Toward #5940

Alternative to #6255

In hindsight, this is a pretty obviously useful function. It took some experimentation until I arrived at it. I have two signatures: this one and the one in #6255. Please express an opinion on which one to move forward with.

How this approach works: it adds a single plain input type named DateTimeInputUnchecked. This type cannot be passed into format because it can't implement the required traits, so it gets its own format function with fallible behavior.

Pros and cons:

• Pro: No weird trait bounds on this function
• Pro: Can construct this type manually without having to implement ICU4X traits or go through ICU4X input types
• Con: Adds a new struct type to the API that we need to bikeshed (where does it live, what is it named, what are its fields named, ...)

[Manishearth]

Let's have the discussion on which option to pick on the other PR to keep things streamlined

[sffc]

I updated this PR to make the fields private and add a few public setter functions.

[sffc]

Wanted to call out the setters I have in this current version of this PR:

• set_date_fields(&mut self, input: Date<A>)
• set_time_fields(&mut self, input: Time)

but for zone, I go field by field

• set_time_zone_utc_offset(&mut self, offset: UtcOffset)
• set_time_zone_id(&mut self, id: TimeZone)
• set_time_zone_local_time(&mut self, local_time: (Date<Iso>, Time))
• set_time_zone_variant(&mut self, zone_variant: TimeZoneVariant)

I did this because

1. If I have type-based setters, I still have 4 setters: UtcOffset, TimeZoneInfo<Base>, TimeZoneInfo<AtTime>, and TimeZoneInfo<Full>, which I find to be more confusing
2. These setters look sort-of like the TimeZoneInfo builder functions, so they are not without precedent
3. What I have implemented here aligns with the needs of ZonedDateTime FFI, which is currently the only client of this function (this is a priority that caries small but nonzero weight)

CC @robertbastian, you probably have an opinion on this