Separate out POSIX zone descriptors in QTimeZone backends

At present, QTimeZone has several backends of which (when feature timezone is enabled) at least the first is compiled:

• UTC-offset: always present
• Platform-specific: MS, Android, macOS, TZ-DB for other Unix, ICU

The TZ backend, used on Linux, includes support for making sense of POSIX time-zone descriptors to identify time-zones. Since 6.6, it also recognises them as available (without
attempting to list them in availableTimeZoneIds(), but isTimeZoneIdAvailable() accepts them, to match the constructor's behaviour). The TZ backend's data files include POSIX time-zone descriptors, so it needs to support parsing these descriptors in any case. However, accepting them as top-level names (rather than components of a data file) complicates some of the logic in QTimeZone and the TZ backend (partly due to the POSIX descriptors not conforming to the rules for validity of IANA zone identifiers).

There is no good reason why we should not accept POSIX descriptors cross-platform.
Setting the TZ environment variable (or content of /etc/TZ) to one is a well-established (if somewhat minority) practice on Unix.
Furthermore, we intend to replace the platform-specific backends with one based on C++20's std::chrono::tzdb; see QTBUG-68812 – this, like the TZ and ICU backends, is based on the IANA database, so probably only (publicly) recognises IANA names for zones.
That transition would thus involve losing support for POSIX descriptors on Unix.

We can break out the POSIX support as a separate backend – that, like the UTC-offset one, we always include, when feature timezone is enabled, falling back to it after UTC-offset and the platform-specific or std::chrono-based one – so as to simplify the logic in various parts of QTimeZone and (until it is retired) QTzTimeZonePrivate.

The implementation of the POSIX backend shall need to expose some internals for use by QTzTimeZonePrivate in its parsing of POSIX descriptors.

It would be perfectly reasonable to limit the support for POSIX identifiers to a separate pseudo-constructor, QTZ::fromPosixId(). Alternatively, we could have that method, separate QTZ::fromIanaId(), QTZ::fromUtcOffsetString() and perhaps others for various forms of ID, along with a constructor that, as at present, permissively accepts any and all (but might get you a different one than you intended in some cases).