Use correct colors for toolbar and headers if high-contrast is active

frameworks/kcolorscheme!43 (merged) adds support for high-contrast on Windows. If high-contrast is active and the user didn't configure a custom color scheme for an app then KColorScheme will use/provide colors defined by the application palette (which is defined by the system provided high-contrast color scheme). For Breeze this mostly works except for colors that are managed by ToolsAreaManager, e.g. the toolbar and the header of KCMs. This is how Kleopatra looks like with the "Kontrast No. 1" high-contrast color scheme on (German) Windows 10 (built with the above kcolorscheme MR and a few tweaks to the application palette because Qt doesn't use the correct colors for disabled text and a few other palette colors):

With the changes proposed by this MR the toolbar and the KCM header looks like this:

Some comments on the changes:

• The first commit aligns the way that ToolsAreaManager detects changes of the color scheme with how it's done by other parts of Breeze (PaletteChangedEventFilter, Style). In particular, listening for QEvent::ApplicationPaletteChange is safer because KColorSchemeManager sets the KDE_COLOR_SCHEME_PATH property before it updates the application palette.
• The second commit resets/clears the config pointer in case no color scheme is set (i.e. "Default" is used) and high-contrast is active. If a null config is passed to KColorScheme then KColorScheme (with the above MR) uses the default color scheme (i.e. for high-contrast the system palette), so that we get the correct colors for the toolbar palette.
• We could almost get rid of the copy of the config held by ToolsAreaManager if it wasn't for KColorScheme::isColorSetSupported which requires a non-null config.

For a bit background information about high-contrast on Windows and how it relates to KColorScheme see frameworks/kcolorscheme#2.