Refactor & isolate eth-service

[karlfloersch]

Is your feature request related to a problem? Please describe.
eth-service is generally a pain point for the operator. There's a lot of deployment logic which is baked into https://github.com/plasma-group/plasma-chain-operator/blob/master/src/eth-service.js#L35-L39 that should be extracted & relocated. It should be very clear from reading the function what exactly is being initialized and when. Also there's a bunch of if statements thrown around checking enviornment variables multiple times like https://github.com/plasma-group/plasma-chain-operator/blob/master/src/eth-service.js#L86

Another issue is we expose a vanilla web3 object as well as a vanilla plasma chain contract object here: https://github.com/plasma-group/plasma-chain-operator/blob/master/src/eth-service.js#L18-L25 -- these should be replaced with a limited API that provides the other operator processes only what is required. Otherwise we are opening ourselves up to weird attacks. No signing logic should be exposed to the outside world--that's crazy.

We also have an issue with eth-db being quite hacky. Really eth-db is wrapper around synchronous calls to write and read from the filesystem. Some of this has been addressed in #35 (thank you!) but generally I feel this thing needs to be rethought a bit. Maybe reading and writing to the filesystem is fine, but we need to store not only the config JSON file, but also a log of transactions which we've sent and the current latest nonce. Making sure that we don't introduce a lot of complexity with this little DB pretty important.

Describe the solution you'd like
eth-service should be refactored. There are two stages of the refactor as I see it. Stage 1) is cleaning up the logic & only exposing a minimal API which is consumed by the server.js parent process. Stage 2) is separating it out into it's own process, decoupling it form the server.js. This way the block-manager can trigger submitRootHash directly without going through the parent process. However, this stage likely requires some sort of message queuing system which needs to be thought out a bit.