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.

[Philip-Larsen-Donnelly]

@jbee ok, this should at least have a unit test.

As for the change, just to be clear, all this does is result in two additional locales (the Uzbek variants) in a blank DB. It has no impact on the rest of the runtime behaviour whatsoever. Currently Uzbek implementations have to manually edit the DB to make these entries directly in the locales table whenever they set up a new blank instance - and they requested these defaults in order to avoid that.

[jbee]

@Philip-Larsen-Donnelly The way I see it is, either we do not need the custom parse function you added because the parsing for locales we have elsewhere can handle it, or, if it cannot handle it, adding these to the DB as you say is asking for errors later on when they do get parsed by the locale parsing that is in place elsewhere. If these have been inserted into DB manually without causing trouble then I suppose you don't need the custom parsing because apparently the locale parsing we have can handle it, or, as I say they just never invoked the operation what would fail parsing them. I would like to to know which one it is before we add this.