Implements the ECMA402 trait for Intl.DateTimeFormat.

[filmil]

Closes: #164

[filmil]

@zbraniecki PTAL

I am still not sure about the options -- perhaps a better choice can be made.

[zbraniecki]

In my ICU4X attempt I did the following logic for https://github.com/zbraniecki/icu4x/blob/datetime/components/datetime/src/options/components.rs and https://github.com/zbraniecki/icu4x/blob/datetime/components/datetime/src/options/style.rs

which uses https://github.com/zbraniecki/icu4x/blob/datetime/components/datetime/src/options/mod.rs

Would it be something worth considering to align here (or there)?

[filmil]

Would it be something worth considering to align here (or there)?

tl;dr: I'd attempt to do (1) from below, unless you think a better approach is available.

Ideally, an interface definition should dictate what the implementation has to conform to. So if at all possible, I'd prefer to try to modify the implementation in icu4x to conform.

In practice, of course, we extract or retrofit interfaces.

I hope that it would be possible to:

1. Try to have the trait definition dictate the implementation if possible. I did that in rust_icu, sometimes at the expense of having to write glue code.
2. Try to keep the trait definition clean of implementation as much as possible.

Now, I think we can't go around implementing the options enum, since the configuration is part of the API surface, unless we're willing to have the trait be "stringly" typed. But let me know if I'm mistaken.

It seemed like a reasonable tradeoff to allow for impls of Options enum to continue existing here, as they are part of the API surface and all spec-conforming implementations must have them anyways.

[zbraniecki]

I'm mostly talking about "nesting" of options into Style vs ComponentsBag. Do you think it may be a good option here?