Restructure remote node processes and allow for multiple connections

[jonatanklosko]

Current design

So far we would start a top-level Manager process on the remote node. This process would then configure the node (register stderr, logger, compiler opts), handle evaluation requests and then clean up on termination. Given the configure-cleanup logic, we generally enforced only a single Manager process per node, and used some additional configuration to handle the Embedded runtime.

New design

Now we split the Manager into separate pieces:

• NodeManager - similarly to the current manager, it's the primary process we start and it configures and cleans up the given node. It then spawns a number of RuntimeServer processes - each for an individual runtime connection. When all RuntimeServers terminate, the manager itself also terminates and does the necessary cleanup.

• RuntimeServer - a remote process behind each %Runtime{}. It's simply responsible for orchestrating evaluation/completion - in short it builds on top of Evaluators to satisfy the requirements of the Runtime protocol.

To initialize a remote node we start a NodeManager and then allow for arbitrarily many runtime connections, each getting it's own RuntimeServer. Once all connections are closed NodeManager automatically cleans up and unloads the dynamically loaded modules.

Implications

Separating node configuration and runtime requests logic makes for a nice refactoring. This also unifies Embedded runtime with other runtime types much more. Finally this makes it possible to connect multiple sessions to the same node using AttachedRuntime (cc @brainlid).

[josevalim]

Just one comment and ship it!