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.
Yeah, agreed.  I'm still not 100% sure of what all the possible states are (or rather, what all the state transitions should be), this started as a number of vars, and I didn't change it too much from the original:

https://github.com/playframework/playframework/pull/3108/files#diff-ba3358b598c5cb41130b7f59ebe0b23aL33

It's also not so simple as there being an init state, error state etc.  I think the states are no change, file changed, force reload.  You have to be careful for example not to transition from force reload to file changed (or to anything else unless a reload actually happens).  Also storing this state in a single variable will mean we either need to synchronise access or use stm.