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.
Since this is a Play internal extension to `BuildLink`, I guess it doesn't mater that we expose Scala types like `Option`? `BuildLink` itself is careful to use only Java types.