Summary
-------

Remove support for the `java.locale.useOldISOCodes` system property

Problem
-------
The `java.locale.useOldISOCodes` system property, originally intended for compatibility, was deprecated in [JDK25](https://bugs.openjdk.org/browse/JDK-8353118). Maintaining support adds unnecessary complexity to the codebase.

Solution
--------

Eliminate the property definition from the `java.util.Locale` class, along with its handling in supporting classes. If the property is specified at runtime via the Java launcher, display a warning indicating that the value is ignored.

Specification
-------------

Modify the `Legacy Language Codes` section in the class description of `java.util.Locale` class as follows:

```
-  *
-  * <p>For backwards compatible behavior, the system property
-  * {@systemProperty java.locale.useOldISOCodes} reverts the behavior
-  * back to that of before Java SE 17. If the system property is set to
-  * {@code true}, those three current language codes are mapped to their
-  * backward compatible forms. The property is only read at Java runtime
-  * startup and subsequent calls to {@code System.setProperty()} will
-  * have no effect. <b>As of Java SE 25, the use of the
-  * {@code java.locale.useOldISOCodes} system property is deprecated.
-  * This backwards compatible behavior will be removed in a future release
-  * of the JDK.</b>
-  *
-  * <p>The APIs added in Java SE 7 map between the old and new language codes,
-  * maintaining the mapped codes internal to Locale (so that
-  * {@code getLanguage} and {@code toString} reflect the mapped
-  * code, which depends on the {@code java.locale.useOldISOCodes} system
-  * property), but using the new codes in the BCP 47 language tag APIs (so
-  * that {@code toLanguageTag} reflects the new one). This
-  * preserves the equivalence between Locales no matter which code or
-  * API is used to construct them. Java's default resource bundle
-  * lookup mechanism also implements this mapping, so that resources
-  * can be named using either convention, see {@link ResourceBundle.Control}.
+  * <p>The default resource bundle lookup mechanism also implements
+  * this mapping, so that resources can be named using either convention,
+  * see {@link ResourceBundle.Control}.
```