IPC interface

Real use-cases:
- IMAP updates generated by maddyctl should be pushed to connected clients.

Potential use-cases:
- Introspection capabilities (such as listing enqueued messages, connected users, etc)
- It is easier to let server synchronize certain operations (take "remove message from queue" as an example) instead of breaking invariants and hoping server code will recover gracefully.

Non-use-cases:
- Moving to microservice-oriented architecture

Considerations:
- We don't intend to make IPC interface stable, thus it should be possible to detect version incompatibility between client and server to prevent problems (user accidentally having different maddyctl and maddy versions). Alternative solution is to merge maddy and maddyctl executable (having `maddy server` to run server and `maddy ctl` for various management).
- It should be possible to pass arbitrary structures (e.g. IMAP updates) and not just simple arguments.
- It should be possible to detect config mismatch between running server and filesystem, maddyctl should prefer requesting configuration from server over reading it on its own. This is important to prevent actions affecting wrong modules or not working at all.

- Access to IPC socket equals read-write access to state directory, socket should be inaccessible for untrusted programs and hence security is not considered.