Implement Internal Persistence and Configuration

[kwiesmueller]

As already outlined in #5 , #3 and #4 configuration and other persistent data inside gorcon should be available at any time for any service.
Going even further #5 outlines the fact, that starting the binary itself should already offer a barebone gorcon mode open for setup through the CLI or API which has to result in some kind of config being stored to keep functionality over restarts.

This requires us to build some kind of internal persistence layer for storing and accessing both configs and other data and also allowing change at runtime with potentially immediate impact on other services.

One pretty good example for this is the internal LogLevel. In an ideal implementation it would be possible to change the LogLevel at any time and see immediate impact.
While this feature might be limited through our use of zap for doing logging, it is a good example.
Other examples are adding scheduler events or updating them on the fly.

The exact design of this feature is not decided yet, all that is clear for now is it's importance for our final vision.
References might be found inside the traefik project which already uses consul/etcd for comparable features.

Acceptance Criteria:

• Dynamic persistence for configs and data inside the entire application
• Accessible by every part of gorcon at any time
• Potential to enact and distribute changes to configs and data at realtime