Locale handling should be improved

[averbraeck]

The use of Locale and DefaultLocale in djunits is not optimal. The following issues should (at least) be repaired:

• use the standard Java names for the Locale files, such as en-US for the US locale and nl-NL for the Dutch locale.
• always format the numbers according to the rules of the Locale.
• remove the DefaultLocale class. Use the en_US locale files for prefixes when the used Locale does not have prefix files. Still format the numbers according to the used Locale.
• add unit tests using different Locales, for reading (parsing) quantities as well as outputting (formatted) quantities.

[averbraeck]

Note that the DefaultLocale in Java is set for the entire JVM. This means that our Locale for displaying units can use a static variable. See https://www.oracle.com/technical-resources/articles/javase/locale.html. Note that every time when a formatted scalar, vector or matrix is printed the code needs to check whether the locale has changed, and load the corresponding resource bundle if it has. The Localization class can handle the reading of the resource bundles.

[averbraeck]

Resource bundles have moved to a subfolder 'locale' in /src/main/resources (/resources in generated jar files), and names of the resource bundles have been shortened (no need to start with 'locale' anymore).

[averbraeck]

UnitSystem points to a static resource bundle loaded as a UnitLocale. Unit did not do this yet, which is quite strange. Let's define a static localization also in the Unit, so it can print names, abbreviations, etc. in a localized form as well. A few extra methods will be created for returning localized unit strings.

[averbraeck]

There are two categories of Locales: those for DISPLAY and those for FORMAT. The FORMAT one takes care of digits, decimal separator and thousands separator. The DISPLAY one takes care of formatting for a user interface in a local language. Therefore, we clearly have to use just the DISPLAY category of the current default Locale. This means that we can, e.g., use Dutch symbols with English formatted numbers,such as 14.2 km/u. Here, the Locale.Category.DISPLAY is nl_NL or nl, whereas the Locale.Category.FORMAT is en_US or en.

[averbraeck]

This test code now finally works (it was commented out in the unit tests because it never worked as intended):

        Locale.setDefault(Locale.US);
        assertEquals("Duration", DurationUnit.MINUTE.getLocalizedName());
        assertEquals("h", DurationUnit.HOUR.getLocalizedDisplayAbbreviation());
        assertEquals("hour", DurationUnit.HOUR.getLocalizedTextualAbbreviation());
        Locale.setDefault(new Locale("nl", "NL"));
        assertEquals("Tijdsduur", DurationUnit.MINUTE.getLocalizedName());
        assertEquals("u", DurationUnit.HOUR.getLocalizedDisplayAbbreviation());
        assertEquals("uur", DurationUnit.HOUR.getLocalizedTextualAbbreviation());

[averbraeck]

Localized methods are available and working.
Unit tests have been added and work properly.
Implications for printing and parsing scalars will be picked up in Issue #3 and Issue #4.