Initial implementation of a Forking-dev-mode runner

Uses sbt-remote-control to connect to a running sbt-server.

How it works:

If

`(fork in run) := true`

Then the run task will fork off the running play app executing the entry
point: `play.sbtclient.ForkRunner.main` passing it:

* base directory for the project
* build uri for the project
* target directory where output artifacts are generated
* project name
* http port
* https port
* poll delay milliseconds for the file watcher

The forked process will then connect back to the sbt-server via the
sbt-client interface. There is a custom task `playDefaultForkRunSupport`
that combines the execution of several tasks and emits them to a remote
client.  This task generates sufficient information to create an
instance of Play's `BuildLink` interface and pass it to the Netty dev
main entry point.  At this point things should more-or-less work the
same as in regular Play dev mode.  Reloading works and errors and
compilation errors are correctly displayed in the web browser.

Known Limitations:

* If the project cannot be built the first time then the BuildLink
  interface cannot be created and the forked process will exit
  immediately.  I think this can be addressed by having a different task
  that feeds non-project classpath info to the forked child and sets the
  reload status to true therefore capturing the error on first load.

* Java compilations failures are not handled.  This is a known issue and
  fixing this has been pushed upstream to the SBT team.

* The forked process may not exit if the parent process exits or if
  communication to the sbt-server is lost.
Merge pull request #3591 from corruptmemory/wip/forked-play-runner-rebase

Initial implementation of a Forking-dev-mode runner