[PSR-7] Describe URIs via UriInterface

**UPDATE**: Per [discussion on the ML](https://groups.google.com/d/msg/php-fig/N53l9apa6K4/Ge7TyxVVvAEJ), I'm leaving this PR open, but no longer considering it as necessary for PSR-7.

This pull request describes a new interface to include in PSR-7, `Psr\Http\UriInterface`, in order to provide consistent access to the members of a URI as composed by a `Psr\Http\Message\RequestInterface`. It defines the following methods:

- `getScheme()`
- `getUserInformation()`
- `getHost()`
- `getPort()`
- `getPath()`
- `getQuery()`
- `getFragment()`

"Query" was chosen over "QueryString" or "QueryStringArguments" due to the verbiage used in [RFC 3986](http://www.ietf.org/rfc/rfc3986.txt) (which refers solely to the "Query" portion of a URI). "Fragment" is provided here for completeness, though in server-side requests, will be absent. "UserInformation" is similarly provided for completeness, as the request URI typically will not contain these details in a server-side PHP application.

Open questions:

- Namespace. I used `Psr\Http`, but that means currently it cannot be served in the same package as the message interfaces (at least, not without defining a different autoloader line). "Http" as a subnamespace is also potentially inappropriate, as URIs are not specific to HTTP.
- Setters. I did not define setters, as the goal is primarily access to the URI segments for a URI composed in a request. Additionally, PHP's `parse_url` provides a mechanism for splitting a URI into its various parts, and this can be used easily from the constructor if provided a full URI from the outset when instantiating an instance. Factories could also easily address the lack of setters. That said, a case can be made for adding them; however, it also makes the URI mutable, which in many cases is undesired (particularly in server-side applications).