Create QLocaleSelector

At present we use QLocale objects to identify translations (and, I gather, voices for text-to-speech output). Unfortunately, this limits us to (language, script, territory) triples for which CLDR has data; if the combination you ask for isn't in CLDR, QLocale will replace some of your choices (starting with any wildcards, the Any members of enums) with alternatives (selected via CLDR's "likely sub-tag" rules) to obtain a triple for which it does have data. This is fine for QLocale itself, but suboptimal for translations (and other similar selectors, such as text-to-speech's voice), where the set of available triples is different.

The correct thing to do for this is to break out the "pick as close a match as we can" logic from QLocale into a QLocaleSelector that packages a test for availability of data with knowledge of the likely sub-tag rules to produce an object to which you pass a proposed triple and get back a best match for which data is available. Then QLocale can use this with "do we have CLDR data for it" test, QTranslator can use it with "do I have a translation available" and text-to-speech can use it with "do I have a voice available".

The result of that (and the triple passed to the query) would in practice be a QLocaleId object; this is currently private, so we would either need to wrap it in some public façade type, that exposes only queries for the language, script and country, perhaps also QLocaleId::name(), or prepare it to be made public. If something like QLocaleId is to become public, it should have a variant field that is currently zero, ready for the eventual resolution of QTBUG-81051, which shall need that field.