Document and revise the physical architecture of the "MVP"

To tackle integration testing, one needs to have a clear picture of what components make the entire system, what are the interfaces that they provide and request, and how they depend on each other, and to what extent a component is made of smaller components.

At the moment (Feb 2020) this picture is missing.

Also missing is the existence of smaller and bigger components; for example most of the components are docker images and no or little use is made of python distribution packages, debian packages, binary libraries, etc. Figuring out if some of these smaller components could be used would make integration testing, development, and maintenance of the system simpler.

This ticket is also related to the release policy mentioned in the Solution Vision https://confluence.skatelescope.org/x/CgWdAw: 

"There is an initial release management policy and tooling with qualification of software versions that can work run together, with the ability of running multiple versions of software on the system, and it is easy to find which artefacts are those.
All teams are used to deploy and test their code in a virtual environment, enabled by the development of simulators where necessary, and their practices are studied by the rest. "