Use PSR-7 RequestInterface instead of internal Request object

[legionth]

This PR uses the PSR-7 RequestInterface to replace the given Request class.

A HttpBodyStream will be used as body for the RequestInterface, which is a ReadableStreamInterface and a PSR-7 StreamInterface. So the body data can still be emitted asnychron and event-driven like before.

Note: The method getQueryParams will be removed with the Request class. This will be handled in a seperated PR which will implement the ServerRequestInterface

Refs #28
Builds on top of #97

[legionth]

Ping @clue. Let me know what you think about the documentation.

[clue]

Awesome feature, but this desperately needs some better documentation! 👍

[clue]

This condition is a bit unclear, see also below.

[clue]

This whole part appears really unclear. How about this:

As defined in PSR-7, the `getBody()` method returns a stream instance which implements the [PSR-7 StreamInterface](http://www.php-fig.org/psr/psr-7/#psrhttpmessagestreaminterface).
Note that the incoming request will be processed once the request headers have been received, which implies that the (potentially much larger) request body may still be outstanding (in a streaming state).
However, most of the `PSR-7 StreamInterface` methods have been designed under the assumption of being in control of the request body.
Given that this does not apply to this server, the following `PSR-7 StreamInterface` methods are not used and SHOULD NOT be called:
`tell()`, `eof()`, `seek()`, `rewind()`, `write()` and `read()`.
Instead, the returned stream instance *also* implements the [ReactPHP ReadableStreamInterface](https://github.com/reactphp/stream#readablestreaminterface) which gives you access to the incoming request body as the individual chunks arrive:

[clue]

This appears a bit unclear, see also above.

Also note its position, how about referring to the above example first and then proceeding with these internals? (telling a story)

How about this:

The above example simply counts the number of bytes received in the request body.
This can be used as a skeleton for buffering or processing the request body.

If you only want to know the request body size, you can use its `getSize()` method.
This method returns the complete size of the request body as defined by the message boundaries.
This value may be `0` if the request message does not contain a request body (such as a simple `GET` request).
Note that this value may be `null` if the request body size is unknown in advance because the request message uses chunked transfer encoding.

[simple example from above here?]

The server automatically takes care of decoding chunked transfer encoding and will only emit the actual payload as data.
The `Transfer-Encoding` header will be removed.

[clue]

?

[User3061]

Good structure: short and clear.

[legionth]

Removed the latest commits about the documentation. @clue wanted to add the documentation for this PR.

[clue]

Updated to include documentation

After talking to @legionth about the documentation, I've offered to support bringing this in line with the stream documentation 👍

[clue]

Yey

At first sight, this looks like a pretty massive PR, but the changes in the examples highlight how little this affects customer code 👍

[WyriHaximus]

[andig]

The inline docs of Server still contain the old request object: https://github.com/reactphp/http/blob/master/src/Server.php#L95

[clue]

@andig Thanks for spotting, I'll take care of this in a follow-up PR! 👍

[stefanotorresi]

I know this has already been merged, but the results of this PR is basically "we implement PSR-7, but you can't actually use that interface, instead you should use React\Stream\ReadableStreamInterface".

Is there no other way?

[clue]

but you can't actually use that interface

While I can't really support this statement, I do understand where you're coming from. Is there anything you're missing or suggesting in particular? 👍