We need this in order to do targeted patching of objects in qmlpreview.

Task-number: QTBUG-142436
Change-Id: I864b3906327e6a1d1778be539bb478ab868f8c45
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>

QtQml.DesignSupport provides QML types for registering and referencing
QML objects. C++ API is also provided for referencing registered QML
objects from C++ side.

The purpose of Object Registry is to provide a convenient way for
design tooling to register objects in generated QML code so that user
can access them in their business logic using a specific key string.
The business logic can be either QML or C++ code.

The types added:

- ObjectRegistry is a type to specify the object you want
  to register into object registry. The object is identified with
  a key.
  The key can be specified either as an attached property of the
  registered object, or the registration can be done with a separate
  ObjectRegistry object using target and key combination.

- ObjectRegistryRef provides the object matching the key,
  which you can then connect to or manipulate.

- MultiObjectRegistryRef provides list of objects matching the key,
  which you can then connect to or manipulate.

- InternalObjectRegistry is an internal singleton type used to scope
  the registrations to one QML engine.

Object registrations are separate for each QQmlEngine.

QObjectRegistryRef and QMultiObjectRegistryRef offer the reference side
as public C++ API for business logic to use. The registration can only
be done in QML code.

Autotests are included.

A manual test application was also added to demonstrate functionality
with both C++ and QML.

Example of simple usage in QML:

import QtQml.DesignSupport
//...
    MouseArea {
        id: myButton
        anchors.fill: parent
        // Option 1, register myButton using an attached property
        ObjectRegistry.key: "MyButton"
    }
    // Option 2, register myButton with a target/key combination
    ObjectRegistry {
        target: myButton
        key: "MyButton"
    }
//...
    ObjectRegistryRef {
        id: buttonRef
        name: "MyButton"

        Connections {
            target: buttonRef.object
            function onClicked(mouse) {
                console.log("Mouse clicked")
            }
        }
    }

Fixes: IDS5-290
Change-Id: I42cc89879d2da4989c6b28e71ee92f681fde3a78
Reviewed-by: Pranta Ghosh Dastider <pranta.dastider@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>

Split the linter parts from QmlCompiler into QmlLintPrivate. This will
allow us to use the DOM in QmlLintPrivate in the future for
QTBUG-127535, to avoid a cyclic dependency between the dom and
QmlCompiler.

Create a new library QmlLintPrivate that contains the
linting-related parts. Make the library static to avoid runtime overhead
due to loading too many libraries, just like we did for the QmlLSPrivate
and QmlFormatPrivate libraries. Move the qmllint plugin type from
QmlCompiler into QmlLintPrivate.

Move the linting-related files from src/qmlcompiler to src/qmllint. Fix
includes to use #include <private/...> where #include "..." failed to
compile. Remove the library names from includes instead of changing
QtQmlCompiler/... to QtQmlLint/... in the file where needed.

Move linter includes from qqmljstypepropagator_p.h into its linter
counterpart.

Add missing export macros to PropertyPrivate, LoggerCategoryPrivate,
and QQmlJSAnnotation so that QmlLintPrivate can link correctly

Adapt qmllint plugins, QmllsPrivate, and qmllint tool to link against
QmlLintPrivate instead of QmlCompilerPrivate

Also update the licenseRule.json file, we want to keep the same
licensing in src/qmllint as in src/qmlcompiler.

Task-number: QTBUG-127535
Change-Id: I52b6d51009886f16b49cd95bf0fcdaeb24490418
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>

It's an internal helper for the windows and macos styles. It depends on
QuickControls2. Therefore it needs to be declared after QuickControls2
but before the windows and mac styles.

This way we can link its backing library into downstream modules. We do
this for two reasons:

1. Link-able modules can be used by qmlsc's direct mode. Plugin-only
   modules can't.
2. If a module is linked and its plugin is optional, we can omit the
   overhead of plugin loading.

Unfortunately, the plugin isn't optional, yet, but still this change is
a step in the right direction.

Task-number: QTBUG-107908
Change-Id: Ied1489ec91b9acdb133181d55a6069216c91375c
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>

Qt Labs provides experimental features and components that
can be changed or removed at any time. This feature can help
to explicitly avoid the usage and will also remove official
Qt features or components that are based on Qt Labs.

Task-number: QTBUG-67720
Pick-to: 6.11
Change-Id: I7a68fc0fa097f671b728951d01f1882f8427b5d6
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>

Task-number: QTBUG-67720
Pick-to: 6.11
Change-Id: I7d9cf0d429ecafd9b77aebbc487b15d5bebb05ab
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>

Using -no-feature-quick-path to build Qt leads to:

    -- Configuring submodule 'qtdeclarative'
    CMake Error at qtbase/cmake/QtFindPackageHelpers.cmake:649 (get_target_property):
      get_target_property() called with non-existent target
      "Qt6::QuickShapesPrivate".
    Call Stack (most recent call first):
      qtbase/cmake/QtTargetHelpers.cmake:288 (qt_internal_register_target_dependencies)
      qtbase/cmake/QtModuleHelpers.cmake:621 (qt_internal_extend_target)
      qtdeclarative/src/quickvectorimage/CMakeLists.txt:8 (qt_internal_add_module)
* QuickShapesPrivate is provided by quickshapes.

    -- Configuring done (37.6s)
    CMake Error at qtbase/cmake/QtTargetHelpers.cmake:187 (target_link_libraries):
      Target "svgtoqml" links to:
        Qt6::QuickVectorImageGeneratorPrivate
      but the target was not found.  Possible reasons include:
        * There is a typo in the target name.
        * A find_package call is missing for an IMPORTED target.
        * An ALIAS target is missing.
    Call Stack (most recent call first):
      qtbase/cmake/QtExecutableHelpers.cmake:162 (qt_internal_extend_target)
      qtbase/cmake/QtToolHelpers.cmake:131 (qt_internal_add_executable)
      qtdeclarative/tools/svgtoqml/CMakeLists.txt:9 (qt_internal_add_tool)
* QuickVectorImageGeneratorPrivate is provided by quickvectorimage.

Pick-to: 6.10 6.11
Change-Id: I4afe3ea5e6ea283d10a4b4837061c8a0822a507a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>

The shared libraries for dialogs have a size of ~2MB for 64bit
and ~1.5MB for 32bit on Android . Even if this libraries are not
used they are deployed in an APK on Android. They also pull in
folderlistmodel from Qt Labs.

Task-number: QTBUG-67720
Pick-to: 6.11
Change-Id: I99f7c1f930b034cfca0d0b0a23c4b25979b94b67
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>

It uses FolderListModel.

Pick-to: 6.10
Task-number: QTBUG-137440
Change-Id: I44cc4f312dddde756bbb33aa7a564c1c4085c75e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>

Arguably targets relevant to tests should be built once all the "source"
targets have been built, since they might depend on them.
For example, in the near future there is a need to include QmlDomPrivate
target to the QuickTestUtils, which is defined only later.

Moreover it's in general a good practice to have a clear separation between
"source" and "test" targets.

Change-Id: I2dd1b41ee4df2227733bab73f983e001daad305c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>