See https://community.kde.org/Frameworks/Frameworks_Logging_Policy

Summary:
the previous logging tech got kind of defunct in 2014 (to the point where
it was basically qCDebug). seeing as no one really complained it seems
reasonable to just move to qCDebug instead and make use of category filters
and other qdebug goodness (such as system logging facilities for the
various platforms)

- new logging category kf5.kconfig.update; at info level by default (i.e.
  unless otherwise configured kconf_update is now silent)
- --debug cmdline option now also attempts to force-enable the debug mode
  on that category (and debugs that attempt in of itself, so we don't get
  confused by categories magically getting enabled).
- all log() calls are now qCDebug calls
- all logFileErorr() calls (which was context-sensitive to the .upd file
  parsing) have been changed to qCDebugFile
- qCDebugFile is a new *macro* wrapping around qCDebug to give it file
  context
- everything is now qCDebug instead of qDebug
- arguments updated to drop excess quoting and spaces to reduce "noise"

https://markmail.org/thread/ofaeqcabguxyohyb

Test Plan: updater still works and debugs when debug is enabled

Reviewers: apol, aacid, #frameworks

Subscribers: kde-frameworks-devel

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D19508

Summary:
This way if another cmake project imports it when cross-compiling, it
can be executed.

Reviewers: #frameworks

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D9652

Summary:
This is particularly useful for cross-compilation, where we only need the
kconfig_compiler on the host system.

Reviewers: #frameworks, apol, aacid

Reviewed By: aacid

Subscribers: aacid

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D6994

We get a CMake warning for reading the LOCATION property, but I don't see
how else to do it (generator expressions don't seem to work)

This allows removing some custom WIN32 API code and is also nicer than
directly calling system()