Proposal: introduce service graph for internal service management

[siennathesane]

Proposal

In order to properly maintain the interconnectivity of the internal processes, a service graph should be introduced to allow for configuration management, dependency resolution, startup, shutdown.

Reasoning

Currently, Pleiades has nearly a dozen internal background processes, singletons, and abstract dependencies that define interconnectivity in the system. These are semi-managed through fx, but fx is not at all the right thing for Pleiades. Not only has it's limitations created non-extensible spaghetti code in server.go, the maintainers aren't interested in a different model, which is totally fine! However, that leaves Pleiades back to the starting line of solving the problem of internal service management.

Spring & .NET have very powerful DI frameworks and ecosystems that allow for not only true dependency injection, but also dependency resolution. I think there are important aspects the service graph should capture and try to emulate for Pleiades.

Acceptance Criteria

Given Pleiades has many interconnected internal processes,
When Pleiades goes to boot,
Then it can properly resolve and instantiate dependencies in the correct order.

[siennathesane]

Implemented by #20

[siennathesane]

After getting through the implementation, I realised my usage of fx was drastically wrong. So I fixed it and I'll get more mileage out of it now.