Strip down ServerEngineWork trait

 - move ExecutionStarting to ServerEngine where we already
   look at the specific subtype of ServerEngineWork
 - adapt ReadOnlyServerEngine to assume there are more
   than one kind of ServerEngineWork

This is groundwork to add kinds of ServerEngineWork that are
not command executions.
add SocketMessage base trait for ServerRequest

This way the socket handler can send things besides requests-from-clients,
which we want to do in an upcoming commit. Stay tuned for another exciting
episode of ... refactoring sbt-remote-control!
Create main logger earlier in SbtServer instead of down in ServerEngine

The purpose of this is to enable logging in SbtServer. It's probably
much more convenient for debugging to have just the one log file
(plus the per-client ones).
Attempt to make server exit or reboot cleanly

Both the queue from socket to ReadOnlyServerEngine, and the
queue from ReadOnlyServerEngine to ServerEngine, can now
send an "EOF" message. These tell the other one to exit.

The "exit" and "reload" sbt commands should now work I think;
so the SbtClient.requestSelfDestruct() API could be dropped, but
leaving it for now.

Various other shuffling to make it work.
Add BuildLoaded and BuildFailedToLoad events

For BuildLoaded you could also just watch for the first
BuildStructureChanged, but this is a little clearer if
what you really want is the first load.

From an SbtClient perspective, a reload and a restart of the
server JVM look the same, so for a given client connection
you would only ever get exactly one BuildLoaded or
BuildFailedToLoad in theory.
Close log file on shutdown of SbtServer

Also, since this required exposing SimpleFileRollingLogger, use
.error to log crash traces from the command engine
On startup rename master.log to previous.log

This keeps us from immediately losing master.log just
because the server restarted.
Force UTF-8 for logs and log the date of creation and rolling.

Also use the PrintWriter constructor that takes a file instead
of rolling our own.
Handle IOException on server socket

We were treating it as an unexpected throwable, but it happens
when we close on purpose.

Also, if we exit the thread for some reason other than closing the
socket, close the socket ourselves.
Handle exceptions during start/shutdown process

Also add a few more diagnostic log messages
Fix deadlock shutting down ServerSocketHandler

When SbtClientHandler calls the closed callback it should not
be doing it from the same thread that someone might be joining.
handle xsbti.FullReload thrown by ServerEngine.execute

Previous code assumed that reload was an xsbti.MainResult but
in fact it's thrown as an exception.

Also the previous code was printing the trace twice
for server engine exceptions.
Flush log stream after a stack trace, and pre-close for good measure.

The docs do say it isn't needed before close(), but superstition is
healthy. Also we don't seem to be getting all the logs sometimes.
Close the connections/ logs so we get those all on disk too

If we don't close it's a leak of course, but it also keeps
the logs from being written.
Log process name from java management API (which includes PID)

Useful in debugging.
Move ExecutionStarting back to synchronized on work queue

It needs to be atomic with removing from the queue, which
I broke earlier.
Add a periodic log-flush timer for when server gets stuck

This may be the last thing we can do to ensure we get
logs without just flushing on every line.

With this periodic flush, if the server hangs we can
see where it's stuck, without it we just see some
arbitrary point up before it's stuck.
Print out initial configuration when executing command engine
Fix TestExecution integration test not to stick a stale server

This does suggest that we have a problem where if a task hangs
we never force-terminate the stuck sbt server, but will save
a full fix for that for another day.
Merge pull request #180 from sbt/wip/havocp-lifecycle

Robustness: logging and clean exit/reboot