Validate use case of qmlimportscanner returning info about a qml plugin without a CMake target

A new CMake code path was introduced in qt6_import_qml_plugins at

https://codereview.qt-project.org/c/qt/qtdeclarative/+/346273/36/src/qml/Qt6QmlMacros.cmake#1786

to try to find a qml plugin's location and link to it even if no CMake target is available in scope for that plugin.

I think this could potentially happen in 2 cases:

1) qmlimportscanner finds a qmldir of a plugin, while it's associated CMake package was not automatically found by find_package(Qt6Qml) nor manually found by a find_package(UserProjectQmlPluginPackage)

2) No cmake package was ever created for the plugin and the plugin was built in a different project. The current project qmlimportscanner could find the qmldir for that plugin by specifying a custom import path to search for, but the CMake target is not available.

In both of these cases, we'd need to generate a plugin_Import.cpp file with a Q_IMPORT_PLUGIN, compile it and link it to the user shared library or executable.

I'd like to remove this code path for now, so that we only use pre-built initializer object plugins as implemented for regular qt plugins at https://bugreports.qt.io/browse/QTBUG-92933 ; basically build and ship the Q_IMPORT_PLUGIN object library when the static qml plugin is built, rather than building the importer when the user project consumes the plugin in a possibly different cmake project.

User projects would then be forced to properly package their plugins if they intend to user them across different cmake projects.

A new warning will be issued in those 2 scenarios.
We can revisit if those use cases are valid later.