Application-specific keys for storing copper-monitoring-client settings

__Problem__
Currently, the SettingsModel of a copper-monitoring-client is stored and retrieved using the hard-coded 'settings' key. This implies that all copper-monitoring-client applications running on a given machine share  the same settings, including application-specific ones, such as 'lastConnectedServer'. More annoyingly, this settings sharing leads to deserialization problems when Copper versions with incompatible SettingsModels are involved. We experience this problem in our OperatorTerminal, which monitors systems using different Copper versions (currently 3.0 and 3.1).

__Resolution__
A contextId has been added to the ApplicationContext. The default value of the contextId is 'default'. The key used to store/retrieve a SettingsModel is now constructed as:`"settings.v" + version + "." + contextId`, where 'version' is the serialVersionUID of the SettingsModel. Therefore, an application that works with Copper 3.1 and does not configure the contextId of its ApplicationContext will use the key 'settings.v2.default'.