Add support for hexadecimal floating-point format in QLocale, QString and QByteArray

Since C99, the standard C printf() family of functions have supported a "%a" format for floating point, displayed in hexadecimal,

a, A (C99; not in SUSv2, but added in SUSv3) For a conversion, the
double argument is converted to hexadecimal notation (using the
letters abcdef) in the style [-]0xh.hhhhp±d; for A conversion
the prefix 0X, the letters ABCDEF, and the exponent separator P
is used. There is one hexadecimal digit before the decimal
point, and the number of digits after it is equal to the precision.
The default precision suffices for an exact representation
of the value if an exact representation in base 2 exists
and otherwise is sufficiently large to distinguish values of
type double. The digit before the decimal point is unspecified
for nonnormalized numbers, and nonzero but otherwise unspecified
for normalized numbers. The exponent always contains at least
one digit; if the value is zero, the exponent is 0.

alongside the more traditional "%[eEfgG]" format specifiers.
Our existing number formatting in QLocale, QString and QByteArray supports the traditional format specifiers, so adding support for "%[aA]" would be natural.
That support uses non-localized representations for bases other than ten; and the printf() family's localized format modifier only applies to decimal output formats, so a locale-independent form is surely acceptable also for this hexadecimal format.

In QString::vasprintf(), the "%a" format is currently handled by treating it as "%f" (which is doubly wrong: not only is it the wrong base, it's not a mantissa/exponent format). This should clearly be corrected at the same time.

The spec doesn't make clear whether the exponent is also in hexadecimal, and what base it represents a power of.
I find (with gcc on Debian) that printf("%a\n", 13.14e14) outputs 0x1.2ac4ddcf08p+50, which is using decimal to specify a power of two.
Verifying the same is true on other C standard libraries would be prudent.

Note that modern standard Unix specifications include also an 'F' format, for which infinity and NaN are given upper-cased instead of lower-case.
This would also be worth adding (and almost no effort – we may, in fact, already support it, by accident, in which case merely updating the docs would suffice).
It is already (at least superficially) supported by QString::vasprintf().