feat: include Uzbek variants in default DB locales

[Philip-Larsen-Donnelly]

This adds Uzbek variants to the default database locales.

The previous code parsed the default strings only one way; which could set the variants, but resulted in locales in the database that couldn't be handled by the core upon retrieval.

The changes here now parse the language, country, and variant parts separately, which results in a locale in the database that is supported without changes elsewhere.

Note that these changes do not affect any of the existing defaults, which remain the same, but only add the two new Uzbek variants in the supported format.
Note also that these defaults only apply to a blank database.

To Test:

1. Run against a blank database.
2. Check the list of default DB locales. They should include the two Uzbek variants (cyrillic and latin).
3. Add a metadata object (like, at least an org unit).
4. Add an Uzbek translation to the object

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jbee]

How do we know the rest of the system can actually handle the locales. There are plenty of Locale from String places in the code. Why would they now handle these correct when you had to introduce parseLocaleString here to make it work? I would think that if this hasn't produced an error yet for you, you just haven't tried the function that does.

In any case we should add at least one test that goes through the scenario you describe in the issue description.