Decide on executable QML module handling

What works already:

• QML modules which use the recommended/promoted folder structure; including
  executables

What would we like to have:

1. A way to avoid having to modify so many paths as in
   https://codereview.qt-project.org/c/qt/qtquick3d/+/362989
   NOTE: Before, only the C++ registered types were in a QML module. The QML
   file(s) were outside of the module, and imported the module with the C++
   types. If there were multiple QML files, they relied on the implicit import.
2. A way to support self imports as in
   https://codereview.qt-project.org/c/qt/qtdeclarative/+/363218

Issues

• One idea to address [1] was to use an empty TARGET_PATH for executables. This
  would most likely work for the specific cases in [1], but it breaks down as
  soon as we have an executable actually relying on the qmldir (e.g. for a QML
  singleton). Without the correct directory structure (reflecting the URI), the
  qmldir will not be found. The only reason that [1] worked with an empty
  TARGET_PATH and did not complain about the missing module is due to the
  registered C++ types, which get loaded at startup. [2] works currently because
  in the resource file system, the module layout is correct. If we were to use
  an empty target path there (and add the self import "import Test" in main.qml),
  the example would fail.

(Non-)solutions

Legend: ! Note
             ✔ Good
             ✘ Bad

A Always mandate a proper QML module layout.

✔ No further work needed on our side
✘ Requires larger adjustments to our examples; gets especially annoying due to
the still necessary qmake support in examples
✘ Requires quite a bit of work for users who want to migrate
=> Does not solve 2, solves 1

B Keep qt6_qml_type_registration for now, and allow "C++ only QML modul" + bunch

of QML files.

✔ Known to work since 6.0
✔ Easy migration from qmake
✔ Does not need much work besides documenting qt6_qml_type_registration
✘ Bad tooling integration (mostly compilers + qmlcachegen; qmllint could at
least be run manually)
=> Does not solve 1, solves 2

C Always generate qmldir in correct place, but adjust file paths

Layout:

 |-main.qml
 |-A.qml
 |-B.qml
 |-Singleton.qml
 |-org
   |-company
      |-qmldir

Contents of qmldir

 A 1.0 ../../../A.qml
 B 1.0 ../../../B.qml
 Singleton 1.0 ../../../Singleton.qml

(no entry for main.qml, as that cannot be imported in any case)

✔ Everything is still a QML module, so tooling is happy
✘ implicit import is not equal to module import (due to potential renaming)
✘ Needs to be implemented
=> Solves 1 and 2

D Copy directory strutcure into current_binary_dir to obtain proper QML module

! would only be used for tooling
✔ qmllint would find all files
✘ Application entry point still needs to be adjusted, and QML singletons would
still not be found
✘ Requires additional implementation work
! Might have unintended consequences
=> Solves 2, partially solves 1 (only if no Singletons are used, and no
reliance on prefer directive or anything else in qmldir)

E Like D, but move instead of mirror

! Could be confusing for users that directory structure changes compared to
source directory
✘ Users must now adjust paths again (at least to find entry point)
✔ We have a proper QML module, tooling is happy
✘ Needs to be implemented
=> Solves 2, but not 1