desktoppackage/configuration: don't prompt for saving if unchanged
Applet configuration presently works as follows: the dialog sets cfg_ properties for everything defined through KConfigXT, and listens to changes to these properties. In addition, configuration pages can send a configurationChanged signal; this is necessary for applets not using KConfigXT or keys that require special handling. If any of the cfg_ properties are changed or the configurationChanged is saved, the configuration is considered changed until it is explicitly saved.
This is a rather awkward user experience, as the user may still be prompted to save or discard changes even if the current values are the same as the currently saved ones – if the user changes a setting and then returns it to the previous states, it's rather confusing to be prompted to save; kcms do not behave this way.
Instead, when a configuration key is changed, we check if any keys are now different from the saved ones, and only request saving or discarding if there is an actual modification to the currently saved config, so e.g. checking and unchecking a checkbox no longer requests saving. Te configurationChanged signal works unchanged from before, for backward compatibility - once the signal is sent, the configuration remains marked as changed until saved or discarded. To allow configuration pages that require special handling for their configuration to integrate with this system, an optional new configurationModified bool property is supported that configuration pages can set to require saving or discarding.
Some configuration pages will need modification to properly support this (if they send unnecessary configurationChanged signals), but it already works for many of them. The containment config pages are among those that need to be adjusted.
This MR should also resolve the main thing that blocked !2619 (closed), allowing us to avoid the barrage of warnings every time a config page is opened. That one will probably also require each config page to be checked for the rare case that they do something funky, so I think it makes sense to do both and then go through all the applet config pages for problems. We're still early enough in the 6.4 cycle that this should be feasible (I don't expect many of them to cause problems).