develop sidecar erlang VM system

Realbook should be able launch a separate erlang VM using distribution. The VM should be responsible for loading and running the modules, which will be thrown away when all registered realbook runs have been completed.

This has the following advantages:

1 - no memory leak issues due to persistent modules/atoms
2 - cleans up open resources
3 - isolates the entire vm as a very large failure domain

The issue names no files, tests, or entry points. Start by examining how Realbook currently loads and runs modules, then determine the distribution and lifecycle design for a separate Erlang VM. Done means the VM isolates module and atom state, cleans up open resources, and is discarded after all registered runs finish.

Written by the indexing model from the issue text.