Derive Eq and Hash in datetime::options

[g2p]

My goal was to use options::length::Bag as a hashtable key, to cache formatters by; and to work with intl-memoizer, which originates in fluent-rs.

The first commit adds just what I need, the second adds the same derives for the experimental formatter options.

The annotated types are all trivial, dataless enums.

[CLAassistant]

All committers have signed the CLA.

[sffc]

The change itself seems fine to me but I'd like @zbraniecki to approve. (Also, we can't land this until after you click through the CLA assistant.)

However I'm not sure if I'm motivated by the use case. ICU4X is designed from the ground up to reduce the need for caches of formatter objects. Unlike in ICU4C, an ICU4X DateTimeFormatter constructor is cheap (though not completely free). One use case where it might make sense to use caches is when loading data from a postcard provider, and we have a tutorial for that.

In other words, don't create a cache just because you think you need one based on experience using ICU4C; do it only if you have actual numbers. I would also be interested in seeing those numbers.

[g2p]

So, I've been creating the cache by following fluent-bundle pushing me in that direction (it's also by @zbraniecki by the way): I can only access a message's locale context by deriving a trait that gets called by a memoizer.
I have no benchmarks showing caching is needed at this point.

Though, to go back to icu_datetime, the DateTimeFormatter docs say this: "For that reason, one should think of the process of formatting a date in two steps - first, a computational heavy construction of DateTimeFormatter, and then fast formatting of DateTime data using the instance."

If I don't cache, I will create a DateTimeFormatter for each date I format; but I'm using the default compiled_data approach so maybe that is acceptable.

(I don't mean to push for this small change if there are good reasons not to. At the moment I've just reimplemented Hash outside using mem::discriminant.)

[sffc]

I filed #4237 to discuss the verbiage of the DateTimeFormat docs.

[zbraniecki]

I'm also hopeful that ICU4X does away with this motivator, but the traits seem reasonable to have on those structs, so it's an r+ from me.

As for Fluent - it has been designed around ICU4C model, and ICU4X may motivate us to rethink how to construct formatters without memoization.

I'm curious if you can measure the difference between constructing new DTF in each memoization call vs actually memoizing it.

[g2p]

I'm curious if you can measure the difference between constructing new DTF in each memoization call vs actually memoizing it.

Yes, reusing is ten times faster (formatting a full datetime):
g2p/fluent-datetime@39133b9

[sffc]

Ok so we're currently at 0.9 vs 9 microseconds. That difference is a bit higher than expected but may be mitigated by #3865 which is currently in progress. Depending on the exact model we land on for icu_pattern, we should be able to approach near 0 on the constructor time if data is built in hybrid or preresolved mode.