Alternate implementation of common resource API

[dlockhart]

This is an alternate implementation of #208 that uses a LocalizeCommon localizer class instead of merging the common resources with the rest.

I feel like this is a bit cleaner, but would require the creation of a LocalizeCommonMixin in core that consuming components extend.

Thoughts?

[dbatiste]

I feel like this is a bit cleaner, but would require the creation of a LocalizeCommonMixin in core that consuming components extend.

What would happen if their component required both their own terms as well as the common ones? Would the terms be in different sets, and if that's the case, would localize find the terms in the lower level mixin in their class?

[dlockhart]

What would happen if their component required both their own terms as well as the common ones?

This is kind of already an issue today when multiple mixins need localization -- although we've definitely had some bugs crop up there as the order of the mixins matters. So yeah, it'd be nice to not compound that problem.

Another option would be to still just leverage LocalizeMixin only with a loadCommon: true configuration flag, and then internally it would just instantiate a new Localize() (like it's already doing) and new LocalizeCommon(). The consumer would differentiate by calling localize('term') vs. localizeCommon('term'). That would allow us to drop the intl-common: prefix from all the common term names -- which was required to avoid collisions with consumer terms.

[dlockhart]

Closing this for now, as we'll proceed with the approach #208. If later we decide to change our mind to something more along the lines of what's in this PR, it should be easy to switch LocalizeMixin over.