Convert measurement system to a user-controlled property of QLocale

At present, measurement system is handled as a property of a locale, determined by its language and territory. The system locale does support consulting a user preference. Nothing that I can see ever does anything with the measurement system (so this is low priority), albeit client code may be assumed to be using it in ways we never thought of.

In reality, different users of a given locale may make different choices of measurement system – for example, Brexiteers might insist on using British Imperial units, while the vast majority of even-remotely-sane citizens of the UK would prefer to use metric, with possible exceptions for travel speeds, journey lengths and the sizes of alcoholic beverages; and anglophone expats living in saner countries might well configure their systems to use their native language – as spoken in either UK or US, whichever they're from – yet want consistent use of metric by their software, because that's what the shops they can get to shall be using.

This is all true not only of the user on whose system our code is run but also of the third parties with whom they may wish to communicate, using recipient-friendly units. (Thus allowing client code to configure this for locales other than the system one is apt to be as valuable as taking into account the system configuration.) Equally, a business intending to ship goods to anglophones in the US or UK may want to customise their communication with them as far as they can, while still being clear that the quantities being sent are being accurately measured in metric units, rather than introducing inaccuracy in how they describe the quantity by converting to incompatible units.

The measurement system information we use is in an ad hoc table, not extracted from CLDR, that is only used by QLocale::measurementSystem(). No source is given for this table, other than a hard-coded column in locale_data that it replaced; that column appears to have been manually added, as qlocalexml2cpp.py contained no hint of its existence. Kristian left no hint as to how he came by it, nor did Lars elaborate on his addition to the table it had become by the time he modified it.

History/archæology of the table and its precursor column:

• 2012-03-22 laknoll added ImperialUK and claimed the UK uses it (also converted from numeric data in the table to symbolic; and added tests) commit 8660f6e385b2070db1b33dab85b5686a00fec06b
• 2008-06-05 ddenis updated to "Unicode CLDR 1.5.1"; added the table, replacing an m_measurement_system (set by a hard-coded column in locale_data) commit 0636d59593f107c3ad5a67b19068ca427efd5828
• 2007-10-30 Kristian Amlie changed the hard-coded column from int to QLocale::MeasurementSystem (without any change to scripts to generate locale_data) commit 8aa16e474632cf886aac646c77b95c1a8cc9f0f8
• 2007-10-30 Kristian Amlie added the column, type and method in a commit "Started implementation of QLocale::MeasurementSystem." with explanation "UNIX part mostly done." commit ae3b0461b33a4e37d2f45898a1d860666b664b9f

Attempts to research the relation between locale and measurement system find only discussion of which countries (i.e. territories) use how hybrid a system, with no hint at there being any dependence on language within any given territory. (Yet the table asserts that, in the USA, speakers of Hawaiian and Spanish, as well as English, use the US-Imperial system; but not the speakers of mainland native languages, such as Cherokee.) A Burmese system of measurement (that seems to have been standardised in terms of British units, presumably during Imperial times; but its units are not whole-number multiples of British ones) is mentioned as in use in Myanmar (Burma). The situation in Liberia is one of official adherence to metric with lingering vernacular use of US-Imperial, much as the situation in the UK is now mostly-metric with lingering use of miles and UK pints.

Given that: (a) all use of the measurement system is in client code, so we cannot guess at what it wants it for and (b) user preference is the only meaningful source of information for it; it seems to me to make more sense to turn our hard-coded table into merely a default value, that the client code can over-ride; that would make it a member of QLocalePrivate, similar in spirit and handling to its m_numberOptions, but with special handling of its default for the system locale, where supported.
At the same time, I think the table used for default value should be simplified to a short list of countries that default to anything other than metric; and we should check for any other systems supported by platforms for which we have backend queries – e.g. does MS's LOCALE_IMEASURE believe in anything but US customary, British Imperial and metric ?