Draft: Added KConfig::ConfigAssociation flag for config files, and deprecated the...

Fixes issue 422529:

The problem with the current situation is that KDE configuration files are all written to the base of the standard config path, and it makes it difficult to determine which ones are in need of backing up \ purging if we want to clean plasma settings independently of KDE app settings, or KDE settings independently of other app settings.

The suggested fix is to require users of KConfig to specify the association of their app - is it a kde application, a plasma component, or "other".

I've added a KConfig::ConfigAssociation enum, which determines where this config belongs. Currently, there are 3 associations:

1. NoAssociation retains the current behaviour, where the config file is written directly under the standard config path.
2. Plasma indicates this is a plasma component and should be saved under a sub-directory called plasma
3. KdeApp indicates this is a KDE application, and should be saved under a sub-directory called kde-app

The bulk of the logic resides in KConfig.cpp, under the new functions makeNewFileNameAndMigrate and getPrefix. KSharedConfig.cpp also got refactored to share code between the deprecated and new openConfig function. The only non-trivial decision I've made so far was to decide that state config should be saved with no association, as they don't require backing up or restoring. But we may want to create a "state" prefix for these.

There are several open issues:

1. How do we want to associate keyboard shortcut settings? Do we keep them outside, in kde-app, in plasma, or should we have a third category?
2. Will KConfigGui be exclusively used by kde applications, so we can write it to kde-app? or do we need to also deprecate its default constructor and require association?
3. Do you agree the KEmailSettings should be save to kde-app?
4. Where do we want kconf_updaterc to reside? (used by KonfUpdate (also, this name seems like a spelling error, it should probably have been KConfUpdate...)
5. There are also kreadconfig and kwriteconfig command line utilities which should probably get additional optional flag for association, and default to no association.
6. I wasn't able to fix all the tests to use the new interface, since I'm not familiar with the autotests framework.

I thought this is a big enough change to begin a merge, and take care of the other issues in a different pull request to make this one easier to follow, since it doesn't break anything yet except producing deprecation warnings, but I'm open to iteratively fix the above issues in this PR as well.