Changes

Add support for environment variable property maps

Previously, it was not possible, to define property maps using
environment variables. The only viable workaround was to define the
property map in the config.properties file and use variables for certain
key values sourced from the environment to inject environment variable
values into property maps.
Although this workaround was functional in a certain way, it did not
allow for the definition of property map keys not present in the
config.properties file nor to override values of property map keys from
the config.properties file that were hardcoded.

This change introduces a mechanism to define property maps using
environment variables with the help of JSON object strings:
MAPPROPERTY={"keya": "valuea", "keyb": "valueb", "keyc": null}
Using this approach it is possible to
- introduce property map values not defined in any config.properties
  file: just create an environment variable with the appropriate name
  and specify the map as a JSON object string.
- define new property map keys: as above, just create the environment
  variable like above with the new key defined. The mixing of property
  map values is explained below.
- change the value of of a property map key already defined in the
  config.properties file: as above, just create an environment variable
  with the key to change and the new value.
- delete a property map key previously defined in the
  config.propertiesfile: as above, just create an environment variable
  with the key to delete and a value of 'null' w/o the quotes.
  The last three options may occur within the same JSON object string
  defined in an environment variable.

When property maps are defined a different levels, the usual precedence
applies: config.properties < environment variable < system property.

Change-Id: I2b2ee1fc472ad1ec29e414ce23a5101e37a7303b
Signed-off-by: Michael Iseli <michael.iseli@bsi-software.com>
Reviewed-on: https://git.eclipse.org/r/c/scout/org.eclipse.scout.rt/+/174274
Tested-by: Scout Bot <scout-bot@eclipse.org>
Reviewed-by: Ivan Motsch <ivan.motsch@bsiag.com>