Fix injecting application locale

[sslavic]

Before this fix, startup of container with seam-international-api on
the classpath would fail with unsatisfied dependency of Locale type
reported for ApplicationBundles.

Temporary fix was to include seam-international implementation as
dependency.

This change makes application locale dependency optional by using
Instance. If application locale dependency is unsatisifed, in
@PostConstruct init method of ApplicationBundles, a JVM default Locale
gets used. If there is more than one Locale eligible for injection,
AmbigousResolutionException will get thrown.

Issue: SEAMFACES-237

[kenfinnigan]

In what situation would you have a dependency on the api and not the impl?

[sslavic]

By just declaring dependency on seam-faces 3.1.0.Final, seam-international api gets transitively included as dependency, but not the seam-international implementation. As can be seen in stacktrace in SEAMFACES-237 issue report, this causes application startup to fail, if application itself that uses seam-faces doesn't also declare seam-international implementation as dependency.

If seam-international implementation is always needed by seam-faces, then it's a bug in seam-faces POMs - along with api they should list seam-international implementation as dependency, or at least they should list that seam-international implementation is expected to be provided (by configuring implementation as provided scope dependency).

If on the other hand seam-faces does not need seam-international implementation, and I'm not planning on using it (e.g. in a simple non-localized PoC or a test) then either api should be self-sufficient (with this patch), or api should be removed as seam-faces dependency if it's not needed / actually used.

[kenfinnigan]

Ok, based on the above I'd say the problem is with the way that Seam Faces defines it's dependency on Seam International. As such, I don't think it's a good idea to introduce work arounds to that problem within this code.