[OAS] Qt OpenAPI Client Generator Support

OpenAPI defines an OpenAPI Specification (OAS), which can be consumed by a an OpenAPI Generator to produce client or server code in various languages. Over a hundred of such generators currently exist.

This Epic proposes adding the capability in Qt to generate Qt HTTP client code from an OAS specification.
There are two fundamental approaches to achieve this:

A) Providing an OpenAPI Generator - project based generator
B) Developing an in-house solution from scratch

There are pros and cons for each approach. Weighing them, the "Option A", providing an OpenAPI Generator project generator, would appear more preferable in terms of tradeoffs. The OpenAPI Generator provides a mature OAS parser, a templating engine, and other foundational features, which would let us focus on what truly matters: building a high-quality Qt 6 client generator.

Some of the cons of this approach are:

• Limited control over parsing and templating internals
• Requires a Java runtime environment
• One-time 30MB download (or system installation) for the core generator JAR (7.11 version)

Despite these drawbacks, the community support and battle-tested infrastructure likely outweigh the downsides compared to writing a generator from scratch.

OpenAPI Generator project already includes a Qt C++ Client generator.
However, merely improving that generator incrementally is not practical. The changes we anticipate would break compatibility and necessitate significant refactoring. Some of these changes are:

• QML Integration / support
• Improved data type support. This includes on-wire and end-user datatypes, but most importantly the latter (eg. QAbstractItemModel)
• CMake-based workflows (for Qt application development)
• Dropping support for OAuth2 in favor of QtNetworkAuth
• Modern Qt 6 best practices (e.g., targeting Qt 6.8 LTS or newer)
• Support for OAS::anyOf(), OAS::allOf(), OAS::oneOf() and friends
• Support for OAS 3.1 features, as much as possible

Apart from environment requirements, the CMake support can abstract away the underlying generator technology. This would later allow swapping the implementation to something different if needed. If the OpenAPI Generator project path does prove itself as a viable long-term solution, the generator(s) could eventually be upstreamed to OpenAPI Generator project.