Lexer for CMake could not parse this broken grammar,
because it is ".cmake.in", not just ".cmake".

CMake itself solves this problems by declaring such code blocks
as generic "::" blocks instead. For example, take a look at the
last code block at CMakePackageConfigHelpers help page:

 - https://cmake.org/cmake/help/v3.18/module/CMakePackageConfigHelpers.html#example-generating-package-files
 - https://github.com/Kitware/CMake/blob/0464298956a204578aa8421ca0b84c089a97e0aa/Modules/CMakePackageConfigHelpers.cmake#L208

GIT_SILENT

Png2Ico provides lower quality icons compared to icoutils as png2ico
predates the current icon standard.
Still lloking for png2ico prints
 * Png2Ico, Executable that converts a collection of PNG files into a Windows icon file, <https://www.winterdrache.de/freeware/png2ico/ or https://commits.kde.org/kdewin>

which confuses new users.

Without this simple space, FindTaglib doesn't appear on
the generated ecm-find-modules.7.html page.

Qt adds the Android ABI to the suffix there unconditionally, without also
adjusting CMAKE_FIND_LIBRARY_SUFFIXES accordingly, breaking find_library()
for things built that way. Unfortunately we can't just set this in our
toolchain file, as CMAKE_FIND_LIBRARY_SUFFIXES is overwritten by CMake
after evaluating the toolchain file. So we need to use the variable_watch
hack for this here, thanks to Aleix for the idea.

With this, find_library() works for both suffixed and un-suffixed libraries
again, such as Poppler built with or without Qt support.

Based on https://phabricator.kde.org/D21695

Several KDE projects use taglib, so we really need to provide a proper
find module in ECM.

AFAIK taglib-config should not be portable, so we don't try to
run it on WIN32. See also:
https://invent.kde.org/network/kio-extras/-/commit/548f525f4308810888c85f42a570139029c40618