Fix use case of linking an executable to a shared library QML module backing target

Context
https://git.qt.io/alcroito/qt6-cmake-api-review/-/commit/14b4999bc857f5402a3577fe334ebfb3602ad0c2#f3ff9c1b48af14adf093e2af0c5cf2849829bb6d_176_236

Currently if a user executable directly links to a shared library QML backing target and doesn't deploy the associated shared qml plugin, if the executable has no references to symbols in the shared library, the linker might decide not to add a dependency on the shared library at all. As a result the qml module will not be found at run time.

The current work around for that is to ensure deployment of the plugins and qmldir files, so that the qml engine can load those.

We could try to fix this issue by creating an object library with a global constructor that references the qml type registration function of the backing library.

This object library would then have to be linked to the executable along with the shared backing library. This would ensure the backing library is not discarded by the linker. This would require CMake 3.21 though, for proper object library propagation.

In some ways this is similar to the Q_IMPORT_PLUGIN object library approach we use for static Qt builds.