Remove hard dependency on IntlMessageFormat

[ericf]

This removes the hard dependency on IntlMessageFormat in favor of pushing people towards first creating IntlMessageFormat instances which they then provide to Handlebars via data.intl.

People should not be putting literal string messages into their templates because these messages are locale-specific, instead they IntlMessageFormat instances should be created once, ahead of time, and then used by Handlebars during template rendering. The whole idea of this i18n suite of packages is to extract the locale-specific strings from the application's templates, code, etc.

App developers will have a collection of string-based messaged per-locale in their code repositories. When their app initializes, those string messages should be converted into IntlMessageFormat instances, and then used throughout the app, including used via this package.

[yahoocla]

CLA is valid!

[caridy]

LGTM, my only concern is that now locales is only used for number and datetime since the instance of messageformat object already have the a bound locale, it is quite different in nature.

[caridy]

let's think more about this.

[ericf]

@caridy yes that's true. But in practice it would be like that even the way we had it before because people would pass-in already-constructed IntlMessageFormat instance.

[ericf]

The difference with {{intlMessage}} and the other helpers is that helpers like {{intlNumber}} or {{inltDate}} take a non-locale-specific value, which is then formatted into a locale-specific string. Whereas with {{inltMessage}}, it's taking a locale-spcific message and formatting it according to the values passed to the helper.

[caridy]

I think we settled on this, and we are going to keep the dependency.

[ericf]

Yeah, it will eventually end up being indirect since we're moving out the formatter cache to its own package which will be the thing that depends on intl-messageformat.