[settings] Serializer Interface

[Montellese]

Description

This PR introduces the ISettingsValueSerializerInterface and its first implementation CSettingsValueXmlSerializer which generates the exact same output as the currently builtin settings XML serializer.

Furthermore I noticed that the ISubSettings handling is currently integrated in the "generic" CSettingsManager but is actually only used in the Kodi "GUI settings" specific CSettings. It is not used for add-on settings or other settings in Kodi. Therefore it makes more sense to move this logic from CSettingsManager to CSettings. This also allows us to directly use the new ISettingsValueSerializerInterface in CSettingsManager instead of the hardcoded / builtin XML serialization.

I plan to do similar work for deserializing settings values and for deserializing settings definitions.

Motivation and Context

For python based scrapers we want to be able to pass the path-specific scraper settings to the python scraper. Since JSON is much closer to python than XML we need a serializer to turn settings into JSON. Therefore I wanted to introduce a clean interface to be able to implement both XML and JSON serialization of settings values. The PR for JSON serialization and scraper integration will follow.

How Has This Been Tested?

I compared the generated guisettings.xml with the original one and they are identical (apart from the order of the settings values).

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[Rechi]

Please follow the current code guidelines.

[Rechi]

Left-align * and & to the base type they modify.

https://github.com/xbmc/xbmc/blob/master/docs/CODE_GUIDELINES.md#52-pointer-and-reference-types

[Montellese]

This change only removes the override keyword. Furthermore a following commit completely changes this line.

[Rechi]

E.g. if the commit which remove this line gets reverted the alignment will be wrong again.

[Montellese]

Yes and if I either fix it in the same commit (which IMO is ugly) or in a cleanup commit and the whole PR is reverted it is also wrong again.

I completely agree that we should follow the coding guidelines in newly added code.
But as long as nobody has fixed all the existing code I'm not going to fix the coding style of every line I touch in existing code. That just makes it much more work to edit existing code and it puts the code into a completely messed up state coding style wise because some lines are fixed but most others are not which results in a mix of completely different coding styles throughout a file.

[garbear]

LGTM