PSA: Qt logging category names of all KF modules have changed for KF >= 5.73 (current master)

[Friedrich W. H. Kossebau]

Hi,

as of this morning, latest master branch of all KDE Frameworks modules has 
seen a change of all the Qt logging category names they define, to now follow 
standardized patterns. Those are described over at
   https://community.kde.org/Frameworks/Frameworks_Logging_Policy

So everyone running KF daily master or later picking up the KF 5.73 release  
will notice the new category names in the log (and the need to update any 
local rules).

Please also make sure that any currently prepared patches for KF modules are 
adapted to the new patterns where needed and new ones using them from the 
start.

Motivation:
So far category names in KF modules were not following a consistent pattern, 
instead it was names like
* org.kde.attica
* org.kde.pim.kcalcore
* kf5.kconfig.core
* kf5.kconfigwidgets
* sonnet.core
* sonnet.plugins.aspell
* kf5.kemoticons.plugin_adium

As a result one could not "calculate" the name which would be used for a given 
library (or feature), but had to first look that up (or rely on 
kdebugsettings & maintained .categories file). Also was it not possible to 
rule all of KF in one go. And the log output with all the different prefixes/
namespaces made it harder to scan.

The polilcy now asks to use these patterns for the category names:

    "kf".<module>[.<library>][.<internalfeature>]
    "kf".<module>.<type-of-plugins>.<plugin>[.<internalfeature>]
    "kf".<module>.<demon/tool>[.<internalfeature>]
    "kf".<module>.<publicfeature>[.<othercode>]

So the examples from above become:
* kf.attica
* kf.calendarcore
* kf.config.core
* kf.configwidgets
* kf.sonnet.core
* kf.sonnet.clients.aspell
* kf.emoticons.adium

See for a more detailed description and reasoning the task
        https://phabricator.kde.org/T12716

Sorry for any inconvenience this change might bring for you right now by 
having to tune your local logging settings to the new names, but in the long 
run you hopefully also gain from the consistent patterns.

Cheers
Friedrich

PS: I am still not satisfied with the current state, would also like that 
there is a central place in each repo to find any category names in use as 
well have them listed in the generated API documentation to ease 3rd-party 
use. I had some draft work, but not happy yet with my approaches, so put aside 
for a bit, will myself only look at later this year again. See for problem 
discussion https://phabricator.kde.org/T12741 (ignore solution part).