Given ECM is released tightly bundled with KF, which itself requires
Qt 5.15 now, and no Linux distribution is known by repology.org which
ships older Qt, but current ECM, that support is considered of no more use.

Given ECM is released tighly bundled with KF, which itself requires
Qt 5.15 now, and no Linux distribution is known by repology.org which
ships older Qt, but current ECM, that support is considered of no more use.

The use of set_package_properties() requires the include, which might
not have been done by the macro consumer.

QQmlImportDatabase::resolvePlugin doesn't accept lib prefixes under
Windows, causing to fail to import when using as a dynamic plugin.

Inspired by kirigami!34

This means removing the find_program() logic, since it was only useful if
we don't want to make CMake spend time finding a compiler; so it was only
useful for building modules that don't need a compiler at all, wallpapers,
icon themes ...etc; so find_program() is only useful when it comes before
the find_package() and enable_language() calls. Thanks to Christophe
Giboudeaux for the explanation. This might make the build time for such
modules a tiny bit longer, but it's worth it to make finding qmake/qtpaths

Fix finding qmake when executable has no version suffix

Like is done in the Qt5 qmake code path.

Some applications look for ECM and need to know Qt paths but
don't need to link to anything. That's the case for icons or
wallpapers.

For these cases, ECMQueryQt will first try to find qmake or
qtpaths before looking for Qt CMake config files.

Also handle cases where project() sets 'LANGUAGE' to 'NONE'.
The CXX language needs to be enabled for find_package to look
for Qt into library dirs.