Http message cleanup

Various cleanups for the HTTP message spec, as discussed on the mailing list.
Two reasons.

1) The set method already allowed a toString-able object, and the parallelism there makes sense.

2) Prior to this, we had discussed a possible PSR for a URI value object.  I don't recall who had proposed it, but it was basically a very direct mapping of RFC 3986 to PHP interfaces.  That to me makes a great deal of sense; especially when dealing with potentially relative URIs, it's convenient to have a builder rather than messing around with string concatenation.  Even PHP itself provides a little bit of builder via http_build_query() (although as is typical for PHP it doesn't go anywhere near far enough).  Whether FIG does it or not, I believe a good structural representation of a URI is a good thing for PHP to have for a variety of reasons.

Such a structural representation would also allow for retrieving parts of the URI without re-parsing it.  Ie, something similar to the result of parse_url(), but as an object that, for instance, lets you look up individual query parameters rather than just getting a string.  That way, I know I can always get a string back from the getter but in some implementations I can also do $request->getUrl()->query('foo') to get back the value of the foo GET parameter without having to mess around with parse_url() and then parsing the query string itself again (and potentially doing that multiple times, which in turn means more opportunity for bugs...)

Put more simply: I want a Url class.  (Drupal already has one, in fact.)  I want it to be compatible with PSR-7.  Allowing a toString()-able object bidirectionally seems like the most flexible way to do that.