Add tutorial and/or public API for creating a DateTimeFormatter from a pattern

[sffc]

We have a number of internal APIs that enable this. It's not something we should encourage, but there are clients who may need this functionality, and it doesn't cost much for us to add it since we use these patterns internally.

@zbraniecki @eggrobin

[sffc]

Note: The call site is in the following file, which uses hard-coded patterns. It might be possible to migrate the client to not use patterns.

https://cs.opensource.google/fuchsia/fuchsia/+/main:src/tests/intl/timezone/src/lib.rs

[zbraniecki]

I think the way I'd like to approach it is by factoring out the code that takes a pattern and a date and populates them into a util - because it is not a date time i18n formatter.

The challenge is that this pattern resolver needs localization data (week names, month names) and number formatter per locale, so we'll need to design that API to take DataProvider and handle locale resolution.

I'm not sure how to name it, but as tempting as it feels to just slap format_for_pattern on DateTimeFormat I think from the architecture and API surface standpoint it would be really preferable to not do that and go through the pain of introducing a new API that is specifically designed to operate on non-i18n date formatting, but localizable pattern elements.

[sffc]

I think that the thing we call raw::DateTimeFormatter could be exported as DateTimePatternFormatter.

[sffc]

• @zbraniecki - A use case here is for someone to pull the pattern from a constructed DTF, modify it, and pass it back in. So we should think about stabilizing the intermediate format.