@aacid related to your MR !245

Basically copied ECMQueryQmake to ECMQueryQt, added copyright based
on git log, with the BSD 3-clause license; based on the contents of the
README.rst file at the initial commit (commit 96e7fb9969b7 by Rohan Garg) of
ECMQueryQmake, the README file says:
     All code is licensed under the BSD 3-Clause license.

Will CC active devs in the MR and email Rohan Garg to confirm.

Then added qtpaths CMake code path, basically you can use query_qt with Qt5
(same syntax, so a drop-in replacement for query_qmake); and Qt6.

The plan is to deprecate ECMQueryQmake in favour of the new module (had to
be done that way as the old module had "qmake" in the name and that could
be a bit confusing).

Semantically this is an ECM module, because it can be used to manage deprecated
Qt API and from any project which use ecm_generate_export_headers

This will make setting the deprecation versions easier, otherwise one would need
to edit the hex value. It also helps to keep the required versions and deprecation versions
in sync.

Also this allows one to keep the deprecation warnings, when one excludes deprecations for a specific version.

Additionally the deprecation version can be overwritten by a cmake parameter.
This will make local testing easier, because one does not need to edit the CMakeLists.txt files.

Task: https://phabricator.kde.org/T15109

This factors out large parts of the common code into separate modules,
and adds a backward compatibility wrapper.

The 6 variant drops some deprecated variables where possible, but otherwise
is the same as the 5 variant. It still lacks a replacement for the paths
depending on ECMQueryQMake though.

Thanks to kossebau for pointing that out.

NO_CHANGELOG

CMake 3.14 ships a module with compatible variables.

- Remove deprecated version checks
- Use VERSION_GREATER_EQUAL