Update ScalaBodyParsers.md
Merge pull request #3704 from DrBoolean/patch-1

Update ScalaBodyParsers.md
Update deploy api docs to include manual
Added manual copy to package script
fix #3711 upgrade async-http-client

backport 16eff6ffb52ab78870b3ac0b46333c189de2db48

fix the following issue:
java.io.IOException: Resetting to invalid mark
with WS.url.post(InputStream)

(https://github.com/AsyncHttpClient/async-http-client/issues/760)

Conflicts:
	framework/project/Dependencies.scala
	framework/src/play-java-ws/src/test/scala/play/libs/ws/ning/NingWSSpec.scala
Merge pull request #3723 from yanns/backport-3711

fix #3711 upgrade async-http-client
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.