Provide a proper node start() and stop() implementation

[aionick]

As per issues #1 and #2, both solutions took minor (albeit acceptable) shortcuts. But these should be done correctly.

The start() method currently launches the kernel and then listens for the rpc server to start via the LogListener, with a 20 second timeout in case the rpc start event had already occurred before we started listening. Instead, we want to be able to begin listening before the kernel is launched so that we are guaranteed to hear the event if it occurs. Also, we should be catching the 'rpc server not started' case and if that occurs handling this properly, since it may also be the case.

The stop() method currently tells the LogListener to stop listening and then shuts the external kernel Process down and waits for it to end. See #2 for why this was the case, there were some troubles (#29 is also related). Instead, we need to shut the external kernel Process down first and then turn the listener off once it sees the proper kernel shutdown line in the log - and if it does not see this, to handle the error.

[aionick]

Once we have finished up #30 we should be a little closer to being able to do this. We probably will also need the ability to submit events to the listener and be able to choose whether or not to be rejected if the listener is ignoring us. Also considering simplifying the listener's state to just alive & dead.

[aionick]

Originally we were thinking we needed some ability to submit events to the listener while it was not listening in order to catch the rpc-started log event in start() but this is actually unnecessary, the solution is simpler.

We can initialize the log file, then start up the listener, then begin listening for the rpc server to activate, and finally then start the node. Until the node is started the listener will simply hear nothing.

Currently we are: initializing the log file, starting the node, starting the listener, listening for rpc.

[aionick]

The solution to the "proper" start() implementation suggested above is quite simple. The LogListener just needs to stop automatically rejecting events if it is not listening.

However, I'm not so convinced the current implementation is wrong, per se. We thought it was because we thought that the transaction pool could not handle receiving transactions before the miners started up but that is incorrect, it can.

As for the stop() implementation, that is really about reporting that the kernel did not shut down gracefully. This may be valuable in that someone would know they now have to manually kill the process, but it is not a huge liability.