Implemented non-blocking run mode

* Used this to implement a dev-mode scripted test.
* Reproduced #2905, but commented the assertions out because I didn't want this PR to fail validation.

Overall design:

* Extended `PlayInteractionMode` to be able to signify that it should be a non blocking interaction mode.  I could have added new methods to the `PlayInteractionMode` trait, but that would probably have broken activator with linkage errors.  So I created a new trait, `PlayNonBlockingInteractionMode`.  It has two methods, a `start` method which allows it to start and store a reference to the running Play server, and a `stop` method which allows it to stop the last server it started.  It expects the Play server passed to it to implement `Closeable`, this is how it stops it.
* Modified (and majorly refactored, simplified, made more idiomatic use of SBT) `PlayRun` to use the new non blocking interaction mode.
* Provided a `play-stop` command for stopping a currently running non blocking dev mode server.

The non blocking run mode does not work with `~run` as you might expect it to.  This can be added later if needed, for now I don't see a pressing need.  I also simplified the implementation of `~run` a little, run used to be a command, not a task, the implementation of `~run` was designed for that, and modified `state` accordingly, but since it's now a task (since 2.2.x), modifying `state` has no effect because you can't pass the new state back to sbt.

The scripted test can of course (and probably should) be extended in future to test a whole range of things, including handling compile errors, handling startup errors, etc.
Daemon threads are for background tasks, regular threads are for things that should keep the JVM from shutting down.  The monitoring for file changes is a background task - it's expected that control will be retained by another thread.  Put it another way, if I type exit into the SBT console while Play is running and monitoring for file changes using this thread, do I want this thread to stop SBT from exiting?  The answer is no, therefore this should be a daemon thread.  In practice, it's not an issue, because when you exit out of SBT it always calls `System.exit`.