Make the JDK11 locale loader to act like the previous ones.

With JDK11, Java now loads locales differently. https://www.oracle.com/technetwork/java/javase/documentation/java11locales-5069639.html#providers details the loading behavior for JDK11, and how it supersedes previous versions. Notably, CLDR, or classloaded entries, now go before COMPAT, or things included with the JDK. This can lead to incorrect behavior with complex classpaths. And localized patterns for the formatting and translation of display strings, such as the locale name, dates, currencies, may be different in some locales.

To supersede this setting, the java.locale.providers system setting is used. It's a comma-separated list of values, where the possible values are the providers in the blog post above. The default value is CLDR,COMPAT,HOST,JRE where JRE is also COMPAT. The value that I would have expected is COMPAT,HOST,CLDR, where it uses the built-in locales first (from JDK9!), then the host locales, then the classloader locales. Setting -Djava.locale.providers=COMPAT will cause the JDK11 locale loader to act like the JDK9 locale loader, and enables a behavior compatible with JDK 8.

The effects of this are seen by the failure of these two tests when compiled on Java 11

org.junit.ComparisonFailure: expected:<Traditional,[]WIN> but was:<Traditional,[ ]WIN>
	at org.junit.Assert.assertEquals(Assert.java:115)
	at org.junit.Assert.assertEquals(Assert.java:144)
	at org.openmrs.util.LocaleUtilityTest.fromSpecification_shouldGetLocaleFromLanguageCodeCountryCodeAndVariant(LocaleUtilityTest.java:184)

and

org.junit.ComparisonFailure: expected:<[tt.MM.uuuu]> but was:<[dd.MM.yyyy]>
	at org.junit.Assert.assertEquals(Assert.java:115)
	at org.junit.Assert.assertEquals(Assert.java:144)
	at org.openmrs.util.OpenmrsUtilTest.getDateFormat_shouldReturnAPatternWithFourYCharactersInIt(OpenmrsUtilTest.java:358)