Streamline QML for better toolability and performance

QML needs some changes to the language and a more modular architecture to be ready for smaller devices and to avoid unnecessary complexity as well as common pitfalls for users.

Architecturally, the current QtQml library needs to be split up into the following parts:

• Compiler/Code model: This should be used as the base for the QML compiler (currently called qmlcachegen), QtCreator's code model and rewriter, as well as the language server to be written. For this to work, it needs some enhancements: We need to be able to edit the code model and we need to be able to emit C++ code or the modified source code as well as the currently supported bytecode for dynamic execution.
• JavaScript engine: The full JavaScript engine needs to be an optional component. Simple binding expressions should be supported without the overhead of garbage collection, dynamic typing etc.
• A runtime library for dynamic execution. This should only be required if you indeed need full JavaScript support or if you are going to dynamically add/remove/change components such as the QML preview does. Otherwise the new version of QML should be compiled to C++ and directly integrated into the application.
• The object model and binding engine. These will be stripped down as far as possible and integrated into QtCore. QML-style bindings will be available through a C++ API and should be useful also in other contexts.
• The debugging and profiling framework.
• Some smaller components like item models or worker scripts.

Furthermore, necessary changes to the QML language need to be identified. The following are already known:

• The implicit resolution of properties in parent objects needs to be avoided. This will allow us to drop all the component versioning and metaobject revisioning.
• Context properties need to be avoided. This will simplify a lot of code and improve performance as we won't need to traverse all parent contexts just to find out that a name does not exist.
• A strict subset of QML shall be strongly typed to facilitate generation of C++ code as well as tooling. The typed properties in QML go a long way already.
• A simplified binding language based on JavaScript syntax needs to be defined. The language needs to prevent any dynamic allocation of objects. This will allow us to get rid of the garbage collector. In order to fulfill the "strongly typed" requirement we may look at TypeScript or consider the JavaScript "var" as something akin to "auto" in C++.
• "private" and "public" qualifiers for properties need to be added to facilitate encapsulation.
• strict QML will do away with any versioning. import statements will state only the name of the module to be imported, not its version. (We might keep the major version in order to allow for things like QtQuick.Controls {1|2}, but that may also be encoded in the name.)

Note that Qt6 will still have a runtime for dynamic QML. QML code shall be declared as strict using a set of pragmas on a file-by-file base. strict QML can then be compiled to C++. We may provide tooling to automatically detect if QML code follows the requirements for compilation to C++ and advise on or automatically add the pragmas to be used. The qmllint and qmlformat tools may come in handy.