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.
No that's not it.  It watches the produced class files and resources - in a simple single module project, this will just watch everything in `target/scala-2.11/classes`.

As for new files - it catches 99.99% of cases.  The SBT source modification checks two things, the number of files/directories, and the most recent modification date of all files/directories.  It's state stores two things, the count of files from the last run, and the timestamp of the last run.  So, generally adding a new file will trigger both of those to change, the file count will change, and the last modification date will be more recent than the most recent scan.  If you copy a file and maintain its modification date, then that may only change the count.  What could stuff it up is if you add a new file with an old modification date, and delete another file, then it won't detect that.  But since this is monitoring the output of a compilation run, that's a very unlikely scenario, the scala/java compliers only ever produce files with new modification dates, and the resource copying - not sure if it has new modification dates but it's probably fine.

Note that the change detection for source files is managed elsewhere, this is only detecting whether the classloader needs to be reloaded after a recompile has been done, to avoid unnecessary reloads when assets change.