It is invalid to pass null as a pointer argument to memcpy/memcmp/memset, even if the count argument is zero:

> Where an argument declared as size_t n specifies the length of the array for a
function, n can have the value zero on a call to that function. Unless explicitly stated
otherwise in the description of a particular function in this subclause, pointer arguments
on such a call shall still have valid values [...]

Detected by -fsanitize=nonnull-attribute.

Generate ASLR-friendly numeric stack traces.

Add Own<T>::attach() which is much like Promise<T>::attach()

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.

This is definitely wrong, because it makes the read/write tasks impossible to cancel and possibly makes them outlive the buffers they are reading from / writing to.

I have no idea why I wrote the code this way, TBQH.

Don't reuse HTTP client connections if the previous request didn't read the entire response.

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

This un-breaks code which previously relied upon an implicit cast from AutoCloseFd to int to call the non-ownership-passing versions of the methods.

Add AsyncCapabilityStream, an abstraction of unix sockets SCM_RIGHTS FD passing.

Implement HttpClient that automatically manages connections. 

Allow KJ_SWITCH_ONEOF to work on const variables

Avoid MSVC workaround in parse/common.h for clang.

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

These are useful in unit tests. Often, some tasks have been queued, and we want to test that a particular thing happens or doesn't happen as a result of those tasks, without actually waiting on any specific promise. We need a way to run the event queue until it is empty. For that, we add WaitScope::poll().

Or, sometimes, we want to check if a specific promise is (or is not!) resolved as a result of the tasks that have been queued so far, but we may not want to actulaly wait() on it for a couple reasons:
- We may actually want to verify that the promise is *not* resolved by tasks so far. wait()ing on it would be expected to deadlock.
- We may expect the promise to resolve, but would prefer not to deadlock if it doesn't resolve (we'd rather fail fast).

For this, we add Promise::poll().

There are lots of tests I've written which could be simplified by this, but for now I'm not refactoring any existing tests.

Note that adding these (particularly Promise::poll()) required updating the async framework a bit, in that this is the first case where PromiseNode::onReady() might be called multiple times, or might be canceled without destroying the PromiseNode entirely. Luckily this was not hard to account for. (We still have the rule that get() can only be called once, though.)

These avoid the need for a read/modify/write.

This allows a lot of nice design patterns, and might later the the basis for capnp 3-party handoff within a machine.

Make win32Socketpair() more secure