Use translation system to slim the TimeZone L10n data

In 6.9 (pursuant to QTBUG-115158) I added lots of CLDR-derived data (c. 2MiB of compiled size) to qtimezonelocale_data_p.h (in qtbase/src/core/time/) to support L10n of the naming of timezones (and the metazones from whose names timezone names are in some cases constructed), controlled by feature timezone_locale, currently enabled when ICU is unavailable on Windows and Linux (perhaps also on some embedded platforms).

It would surely be possible to adapt the data-generation of this to produce

• The much smaller en-US data set (potentially allowing significant simplification relative to the 6.9 tables); this may even be ASCII-only, allowing use of 8-bit data instead of 16-bit;
• A translation file using those en-US names and translation contexts along the lines of "QTimeZone ZoneName", "QTimeZone MetaZone", "QTimeZone Exemplar";
• Translated data files for all other Qt-translation-supported locales (in so far as CLDR provides translations for each) ready for use by the translation system.

We could then, presumably, use the translation system to do the L10n parts of QTimeZone::displayName() and friends. Benefits:

• Much smaller binaries for platforms using the timezone-locale feature;
• User choice of which translations to install would mean they only get what they actually want of the (now separate) L10n data;
• If our translators fill in the gaps not filled from CLDR's data, or correct errors in it, we get improved L10n data;
• We could even use the translations when our backend isn't using timezone-locale, as a fallback when the backend lacks a suitable L10n for a given zone name;
• If the locale-timezone code's performance beats some backend at zone-name L10n (there is an open bug about ICU's backend being slow, for example), we could even provide the option of enabling timezone-locale, for those systems, for users more concerned with performance than disk use.