Qt Quick Controls 2 was named that way because it was a follow-up to
Qt Quick Controls 1.x. Now that Qt Quick Controls 1 is no longer
supported, we don't need to have "2" in the name. Work on this was
already started for the documentation in
1abdfe5d5a052f2298b7bf657513dfa7e0c66a56.

By doing this renaming a few weeks before feature freeze, it won't
affect the release but still results in as little time possible spent
manually fixing conflicts in cherry-picks from non-LTS releases as a
result of the renaming.

This patch does the following:

- Renames directories.
- Adapts CMakeLists.txt and other files to account for the new paths.

A follow-up patch will handle documentation.

It does not touch library names or other user-facing stuff, as that
will have to be done in Qt 7.

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

Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.

Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>

Including moc files directly into their classes' TU tends to improve
codegen and enables extended compiler warnings, e.g. about unused
private functions or fields.

Pick-to: 6.3 6.2 5.15
Task-number: QTBUG-102948
Change-Id: Iac3f0f54ecd734d8558645094f6373dd9335852b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>

Remove usages of outdated LGPL3 header that references LICENSES.LGPLv3
instead of LICENSES.LGPL3.

Change-Id: If7a90ec18331a68491c5a740f131a5e7b3f37df4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>

The existing implementation was removed in order to reduce massive code
duplication and simplify color resolving process. Unit tests were fixed
accordingly.

See related changes in the qtdeclarative module for the further details.

[ChangeLog][General] the palette API is a part of
QQuickItem now.

Change-Id: Ic94ab4632e626c11d9b26f035e2a8a119c9088ef
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>

 Conflicts:
	.qmake.conf
	tests/auto/controls/data/tst_combobox.qml

Change-Id: I8471cdac4397f77a8e58140d58c6b50d3c437928

Check if the user has set Accessible.name before setting it to the
control's text/title/etc.

Fixes: QTBUG-66583
Change-Id: I8b2c8ab3f8a8ae8e76c8e6a241260b7f90eca254
Reviewed-by: Liang Qi <liang.qi@qt.io>

Change-Id: Icb923b10d2b6c524ebaa8b38c7979b780e3582d4

Up until this patch, we've always deleted "old" items when a new one is
assigned. For example, the style's implementation of contentItem will
be destroyed here as it is not accessible by the user and is no longer
used:

    Button {
        contentItem: Item { /* ... */ }
    }

This was especially important before the introduction of deferred
execution, as the "default" items would always be created, regardless
of whether the user had overridden it with one of their own items.
By deleting the old items, we free unused resources that would
otherwise persist until application shutdown (calling gc() does not
result in the items being garbage-collected, from my testing).

Although this has largely worked without issues, deleting objects
that weren't created by us in C++ is not supported. User-assigned items
can be created in QML (with JavaScriptOwnership) or C++ (with
CppOwnership), and it is up to the user and/or the QML engine to
manage the lifetime of these items.

After the introduction of deferred execution, it became possible to
skip creation of the default items altogether, meaning that there was
nothing to delete when assigning a new, user-specified item. This
requires that no ids are used in these items, as doing so prevents
deferred execution. Assuming that users avoid using ids in their items,
there should be no unused items that live unnecessarily until
application shutdown. The remaining cases where items do not get
destroyed when they should result from the following:

- Imperative assignments (e.g. assigning an item to a Button's
  contentItem in Component.onCompleted). We already encourage
  declarative bindings rather than imperative assignments.
- Using ids in items.

Given that these are use cases that we will advise against in the
documentation, it's an acceptable compromise.

[ChangeLog][Important Behavior Changes] Old delegate items (background,
contentItem, etc.) are no longer destroyed, as they are technically
owned by user code. Instead, they are hidden, unparented from the
control (QQuickItem parent, not QObject), and Accessible.ignored is
set to true. This prevents them from being unintentionally visible and
interfering with the accessibility tree when a new delegate item is
set.

Change-Id: I56c39a73dfee989dbe8f8b8bb33aaa187750fdb7
Task-number: QTBUG-72085
Fixes: QTBUG-70144
Fixes: QTBUG-75605
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>

The warnings were about:
- Undocumented function parameters
- Instances of \instantiates that us an internal class
- A few link issues

Task-number: QTBUG-79827
Change-Id: I60094279c7da6bc446b5c63b7b4924b71cee4672
Reviewed-by: Paul Wicking <paul.wicking@qt.io>