Closes #408. Perhaps the same bug as in commit cff9ba05?

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.

MSVC refuses the following code:

struct Foo { Foo(Foo&) {} };
Foo foo;
[foo] {}();

because it only seems to want to consider const copy constructors when
capturing objects by value in lambda capture lists.

We could also port this by using the deprecated MSVC compiler intrinsics,
but:

1) They're deprecated,
2) I've never used them,
3) We'd need to sprinkle some #if's in the code to support both MinGW and
MSVC, increasing the maintenance burden.

The calling convention must go inside the parentheses when declaring a
function pointer.

WINBOOL is apparently a MinGW-ism.

Disallow MSVC from building the parsing code by default because the latest
stable MSVC (VS2015 Update 3) ICEs when trying to compile the `anyOfChars`
combinator.

Note that VS2015 Update 2 and VS2017 can compile the parsing code, with a
little help. To experiment with this, you can override the default
behavior with -DCAPNP_BUILD_TOOLS=ON.

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

- AsyncInputStream::tryGetLength() can report the amount of data the stream will produce. Useful for implementing HTTP Content-Length header.
- AsyncInputStream::pumpTo() copies data from an input stream to an output stream, using double-dispatch to find an optimal approach.

Re-introduce async-io.c++ containing just the default implementations of methods on the abstract interfaces.

Rename async-io.c++ to async-io-unix.c++, in preparation for factoring out common bits from async-io-win32.c++.

These methods are useful if you're receiving a generic stream in
application code and would like to check some non-stream behavior about
the file (e.g. stat or isatty).  Of course, downcasting can fail and
code should not rely on the file descriptor being available.

The implementation used by AsyncStreamFd was simply calling the general tryRead(), so why not?