Psr 7

**Do not merge, this ticket just exists for tracking purposes until its done**

This branch migrates sabre/http to [PSR-7][1]. PSR-7 solves the same problem what our `RequestInterface`, `ResponseInterface` and `MessageInterface` also solve.

Because of the benefits of standards-compliance and the potential ecosystem that may spawn around this, we'll start supporting this in a next major sabre/http version, 4.0.

Todo:

- [ ] 100% unittest coverage of new methods.
- [ ] PSR-7 must be released.
- [ ] RequestDecorator now only accepts the `IncomingRequestInterface` variant. It should also work for the plain `RequestInterface`.
- [ ] The Client should ideally typehint on the generic PSR request interface, not just the Sabre one.

## Changes

### Bodies are now represented by a Stream object.

For a lot of real-world use-cases that we used address, using a stream object is unfortunately a bit clumsy, and due to the nature of the Stream object, we can also not fully provide backwards compatibility.

`getBody()` now returns the `Stream` object (which is pretty much a direct implementation of `StreamInterface`). This object can accept both a `string` or a `stream` as its main argument.

`setBody()` _must_ receive a StreamInterface-compatible object now. This means a lot of changes in sabre/dav unfortunately. Because it's a strict method signature, we're also not able to provide backwards compatibility.

### Request vs. IncomingRequest

Our `Request` always was what the new PSR `IncomingRequestInterface` now is. The `IncomingRequestInterface` is specifically for the 'server' use-case.

However, since these are mostly value objects, we don't really see a reason to split these up. So our `Request` object is in fact the PSR `IncomingRequestInterface`, and we don't have a separate `RequestInterface`.

### Methods that have been renamed

| Old | New |
| ---- | ---- |
| `Message::setHttpVersion` | `Message::setProtocolVersion` |
| `Message::getHttpVersion` | `Message::getProtocolVersion` |
| `Request::setPostData` | `Message::setBodyParams` |
| `Request::getPostData` | `Message::getBodyParams` |
| `Request::getQueryParameters` | `Message::getQueryParams` |
| `Response::getStatusText` | `Message::getReasonPhrase` |
| `Response::getStatus` | `Message::getStatusCode` |

For _all_ of these methods we provide backwards compatibility through 3 new traits:

* `Sabre\HTTP\BC\MessageTrait`
* `Sabre\HTTP\BC\RequestTrait`
* `Sabre\HTTP\BC\ResponseTrait`

In a major version after version 4.0 we will remove these traits.

### Methods that will be removed

The following methods still work, but will be removed in a major version after 4.0:

* `Message:addHeaders`
* `Message:setHeaders`

The following methods also still work, but their semantics have changed a bit:

* `Message:getBodyAsString`
* `Message:getBodyAsStream`

The most important thing here is that while these methods still exist, you absolutely _must_ reinitialize the stream object after using it _if_ you want to be able to read the body more than once.

This means that when you call either of those methods, you should call `setBody()` after with a valid value.

Lastly, `Response::setStatus`.

This was a handy method to set either just a status code with a default phrase, or set the status in one go:

```php
$response->setStatus(200);
// is now
$response->setStatusCode(200);
$response->setReasonPhrase(Response::$statusCodes[200]);

// and

$response->setStatus('200 OK');
// is now
$response->setStatusCode(200);
$response->setReasonPhrase('OK');
```

This is not as pretty, so maybe we can find a better workaround.

### New Features

The Request object now also contains references to:

* `$_FILES`
* `$_COOKIE`

### Decorators can now decorate *any* PSR-compatible object.

This will allow people to use use the decorators even if their Request and Response objects are created by 3rd-party systems.

[1]: https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md
looks like a endless recursion ;-)