Missing support for PLUGIN_EXTENDS (qmake) and QT_PLUGIN_EXTENDS (CMake) with Qt static builds

In Qt5, each static plugin project can declare that it should be linked by default into an application, only if a certain Qt module is linked.

This is done in the qmake project by setting the PLUGIN_EXTENDS variable. An example of that is the svg icon plugin and the cmake auto tests mock3plugin

https://github.com/qt/qtsvg/blob/5.15/src/plugins/iconengines/svgiconengine/svgiconengine.pro

https://github.com/qt/qtbase/blob/5.15/tests/auto/cmake/mockplugins/mock3plugin/mock3plugin.pro#L9

Basically

   PLUGIN_EXTENDS = svg

means the plugin will be linked if the application links against the QtSvg module and

 PLUGIN_EXTENDS = mockplugins1 mockplugins2

means that the mock3plugin plugin will be linked if the application links either against Qtmockplugins1 or Qtmockplugins2 Qt modules.

This is handled by qt.prf here https://github.com/qt/qtbase/blob/5.15/mkspecs/features/qt.prf#L85

We tried to implement the same behavior for Qt5 cmake support, but it doesn't actually behave like that, we merely compare some property values.

https://github.com/qt/qtbase/blob/5.15/mkspecs/features/data/cmake/Qt5PluginTarget.cmake.in#L113

What we should do is check if the final CMake target links against a specific Qt module (the one in QT_PLUGIN_EXTENDS).

This might be difficult to do because writing a genex like

$<STREQUAL:<TARGET_PROPERTY:LINK_LIBRARIES>,QtSomeModule>

will not catch transitively linked Qt modules.

This is alluded too by the comment at
https://github.com/qt/qtbase/blob/5.15/tests/auto/cmake/test_import_plugins/CMakeLists.txt#L47

Now the Qt 6 part.

pro2cmake didn't actually port qmake's PLUGIN_EXTENDS information to CMake, so we lost that information.
Which means qt6 qmake projects will regress.
And qt6 CMake projects don't handle any kind of PLUGIN_EXTENDS functionality at all.

It's difficult to gauge how important of a feature that is. I suppose some qmake projects might break. At least that's the current state.

We should at least restore the qmake behavior, which will mean creating some new API option for qt_internal_add_plugin and annotating all plugins with the lost information, so we generate correct qt_plugn_foo.pri files.

Ideally we find a way to make it work with CMake, but that's probably less critical.