add support for full or partially updating Config params from SSM

[petrkalos]

Feature or Bugfix

Feature

Detail

Currently data.all reads the config that is commited to the root directory of the repo.
In this PR we allow customers to customize the params as defined in the config.json (or completely overwrite it) using an SSM parameter (/datall/{ENV}/configjson).
The new workflow will be as follows

1. Read the config.json (as always)
2. Read the configjson SSM param and merge it with the contents of config.json (essentially overwriting the specified params)

This is useful for the following cases...

• Running a CI/CD pipeline directly from GitHub repo and want to customize the behaviour
• Running multiple stages/envs (dev, uat, prod etc) and want to customize them separately

Relates

• Integration tests executed on a real deployment as part of the CICD - Environments #1230
• Feature Flags for different environments like Dev, UAT, Prod #1136

Security

Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

• Does this PR introduce or modify any input fields or queries - this includes
  fetching data from storage outside the application (e.g. a database, an S3 bucket)?
  • Is the input sanitized?
  • What precautions are you taking before deserializing the data you consume?
  • Is injection prevented by parametrizing queries?
  • Have you ensured no eval or similar functions are used?
• Does this PR introduce any functionality or component that requires authorization?
  • How have you ensured it respects the existing AuthN/AuthZ mechanisms?
  • Are you logging failed auth attempts?
• Are you using or adding any cryptographic features?
  • Do you use a standard proven implementations?
  • Are the used keys controlled by the customer? Where are they stored?
• Are you introducing any new policies/roles/users?
  • Have you used the least-privilege principle? How?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[petrkalos]

Closing because @dlpzx pointed out that CDK also reads this config file hence changing it dynamically is not a very good idea. We need to come up with a better plan.