@aacid related to your MR !245

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.

templates are very useful as teaching tool in order to make
a minimal application that uses a certain framework.
templates in the KAppTemplate repository will always get forgotten
(plus kapptemplate is not really necessary as they work in kdevelop as well)
An ideal situation would be frameworks having templates in their own repos
with templates of barebone apps using the main framework features.
In order to do that, the cmake stuff needed in order to correctly install
a template needs to be ported to a place avaiable to all frameworks

REVIEW:126185

This is deliberately modelled very closely on CMake's documentation
system.  It's a hefty patch, because it involved changing all the
documentation to be in reStructuredText format.  I also cleaned up the
copyright/license statements at the same time.

Note that the find modules contain the full license, due to the fact
that ecm_use_find_module() copies them out of the ECM distribution.