(Or if it didn't send the entire request body.)

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".

The proxying code was responding to a `Close` message by ending the pump loop, which had the effect of immediately dropping the connection after a `Close` had been seen in each direction. This is arguably incorrect behavior: for proxying purposes, `Close` messages and underlying TCP disconnects should be treated as independent events, forwarded separately.

In practice this "bug" probably would never cause a problem and perhaps doesn't even violate spec (since `Close` was seen in both directions). But, OSX's implementation of shutdown() returns ENOTCONN if the connection has already been disconnected from the remote end. This is the case here, as the proxy dropped all connections immediately after sending the final `Close`.

This in turn led to a unit test failure.

The intended behavior was that the proxy would forward exactly what it saw: If a `Close` was sent, it would be forwarded, without changing the underlying connection state. If a TCP disconnect was detected, it would be "forwarded" by disconnecting the next leg. This change implements that behavior.

Due to differences in the way I/O events are queued on Windows, the timing of this test end up different, such that the two incoming pings are not both received before the large outgoing message is sent.

To fix this, I removed the dependency on native I/O altogether by implementing an in-memory pipe that does no buffering (it requires a read() and write() to rendezvous, then copies between their buffers).

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.

The entity-body would never be marked "done", breaking the pipeline for subsequent requests/responses.

(In practice `Content-Length: 0` is rare since normally only GET requests don't have content and they don't pass `Content-Length` at all.)

Otherwise, the HTTP client might be destroyed before it has written all data, since the responses have already been received.

In particular this fixes http-test on Win32.

Fixes https://github.com/sandstorm-io/ekam/issues/13
Fixes https://github.com/sandstorm-io/ekam/issues/11

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).