We don't support any extensions currently, but it's important that when acting as a proxy, we don't pass through this header, since it could result in the client and server negotiating extensions that the proxy doesn't understand and will botch.

There are actually two new client types:
- One which always connects to a given NetworkAddress, but will automatically manage a pool of reusable connections.
- One which looks up the remote address based on the URL it is given, and manages a pool of connections for each host.

The latter of these two is a "true HTTP client library".

This really is more of a data structure than a resource type, and it's useful to be able to share it between threads and whatnot.

Still need to add handshake separately.

This uncovered some bugs and revealed that there was no way to read the Content-Length of a HEAD response. Fixed.

or, the world's least significant pull request.

This reverts commit f836a5fc.

The old semantics were intended to allow more implementation freedom, but I find in my actual code it's very convenient to rely on the actual implementation details. Other implementations will just have to deal with it.

Properties:
- Presented as a LIBRARY, designed to be unopinionated about the application using it.
- Uses KJ async framework.
- Header parsing is zero-copy. The whole header block is read into a contiguous buffer, then parsed all at once. Avoids complicated state machinery (and is probably pretty fast).
- Known headers are parsed to numeric identifiers so that the application doesn't need to look them up by string name. The app registers all headers it is interested in upfront, receiving numeric IDs for each. Some common headers also have pre-defined constants, avoiding the need for registration.
- Connection-level headers (e.g. Content-Length, Transfer-Encoding) are handled entirely internally.
- WebSocket support (planned).

Not done yet:
- Implement the version of HttpClient that connects to new servers as-needed, managing a pool of connections. Currently I've only implemented the version that takes a pre-existing connection and speaks HTTP on it.
- Implement WebSockets.
- Implement plugable transfer encodings (although I guess Chrome doesn't even support transfer encodings other than chunked; maybe it's a lost cause).
- Implement HTTP/2, hopefully transparently (... someday).