Factor launcher instance out of EnsimeClient entirely #325
Description
I'm on a mission to, piece by piece, strip EnsimeClient's responsibilities down to connecting to a server, sending it requests, and dispatching the responses to handlers. This is up for debate, but I think its attempts to manage its own server process lifecycle should be extracted.
EnsimeClient takes an instance of EnsimeLauncher as a constructor param. IMHO abstraction-wise, and testing-wise, the client object shouldn't really have anything to do with a launcher instance directly: the server should be launched, then that job is done and a client can be instantiated (it's useful to instead pass only the parsed .ensime project config—launcher.config—to the client constructor, and that makes sense to me abstraction-wise).
Within EnsimeClient, the launcher instance is essentially only used in the setup() method, which is called constantly on cursorhold (!!) with weird and confusing parameters. In a convoluted way, this serves as a process monitor, potentially re-launching and reconnecting if the server dies. I feel that all of this can and should be moved out to either the Ensime class or some kind of separate watchdog class that it instantiates. It can just call a reconnect() method on the client when needed, or possibly tell Ensime to create an entirely fresh client instance, whatever makes sense.
Goodbye, launcher and ENSIME process handle attributes of EnsimeClient.
This most likely ends up having some substantial overlap with #294. I've got a little bit of WIP on that, but I've got a little bit of WIP on a lot of things so I don't want it to deter anyone else from picking up these tickets, just ping me in case I can help give you a head start.