Rationalise Hyperion deployment-time configuration

The config server provides a convenient mechanism for run-time configuration of behaviour.

However the situation is messier for things that need to be configured at deployment-time:

* IPyB and Zocalo credentials and endpoints
* Config server endpoint itself
* blueapi client and server configs (for `hyperion-supervisor`, `hyperion-blueapi` and the external callbacks)
* watchdog port
* log file endpoints
* hyperion blueapi endpoint

These are currently configured by a mish-mash of environment variables, configuration files and launch parameters, and need to be managed consistently across GDA, hyperion-blueapi, hyperion-supervisor and external callback processes, all of which have different entry-points where configuration might need to be initialised.

This becomes doubly confusing inside unit and system tests where we may need to mock or inject configuration to point to test instances.

Kubernetes deployment may help somewhat with the management of production deployment through helm charts, however it would be good if we had something to address the issues for development and test.

## Acceptance Criteria
- There is a common centralised point of configuration where such config is accessed can be injected for the purposes of testing across hyperion-supervisor, hyperion-blueapi and external callbacks