Define the architecture of helm subcharts and repositories

In order to organise the SKAMPI deployment and configuration in a series of sub-charts hosted in the each separate repo, some decision is needed in order to uniformly represent the sub configurations and the related parameterisation.

P.Harding original comment:

I think we got a long way towards proving that the sub-charting can be achieved during the support work of this PI (7).  There is still an amount of design work that needs to go into determining how the sub-charts should be managed, and how we want them to interact, how we want to make use of in-built helm testing features and hooks, how we manage dependencies (mostly to do with tango-base), but this could sorted out with some good discussion between the stake holders.

Also, the ability (demonstrated at the proj-mvp meeting) to turn git repos into "cheap" helm repositories that align charts with their application might help with the breakup, and organisation of the MVP components - so that needs discussing too.

Inline with the work in ADR-5 https://confluence.skatelescope.org/display/SWSI/ADR-5+Characterisation+of+deployed+software+configuration , the handling of configuration (essentially values.yaml) must take into account version control for QA'ed releases, integration with CI/CD, and future requirements for the secure and reliable handling of secrets and service metadata.