Make HttpClient adapter preserve exception behavior

Ideally, the HttpClient/HttpServer adapters should maintain the invariant that
the behavior of a given client is the same as the behavior of
newHttpClient(newHttpService(client)).  Prior to this change, the HttpClient
wrapper lazily called request(), so a client whose request() eagerly threw an
exception could produce a different exception when called directly versus when
wrapped -- the laziness allowed additional code to run.  This was particularly
evident when making a request with a body, since code using a wrapped client
would be able to set up a subsequent BlockedWrite, eventually resulting in a
"read end of pipe was aborted" exception instead of the actual exception.

This change makes HttpClientAdapter::request() execute the wrapped request()
eagerly.

(Note that it partially undoes 90d48343... Hopefully, it preserves the desired
behavior added there.)

Detect and report when a HashMap suffers from excessive collisions.

Fix failures in http-over-capnp-test.

`task` needs to be the last member of ServerRequestContextImpl, because when we construct it, we call `service.request()`, which may call back to send() or acceptWebSocket(), which require `replyTask` to be initialized.

And fix a bug detected by this.

Various bug fixes

The RPC system itself can sometimes call `releaseParams()` redundantly after the application has already called it. So, it's important that it be idempotent.

Add std-iterator.h to build files

Suppress MSVC warnings in headers files

Add compat/std-iterator.h

Allow including a header to obtain the iterator traits instead of
needing to carefully define a slightly more obscure macro that someone
might be tempted to define globally.

For Visual Studio we have to wrap the headers with push/pop pragmas
at the top and bottom of the file.

Define common macros for suppress/unsuppress KJ & the appropriate macros
for CAPNP begin/end header wrappers. Because there's a chicken egg
problem the KJ_BEGIN_HEADER/CAPNP_BEGIN_HEADER macros are placed below
all includes to ensure that the appropriate common.h file has been
sourced.

Fixes #889.

Fix handling of queued RT signals, plus some other crap

For regular (non-RT) POSIX signals, the process can only have at most one instance of each signal queued for delivery at a time. If another copy of the signal arrives before the first is delivered, the new signal is ignored. The idea was that signals are only meant to wake the process up to check some input; the signal itself is not the input.

POSIX RT signals are different. Multiple copies of the same signal can be queued, and each is delivered separately. Each signal may contain some additional information that needs to be processed. The signals themselves are input.

UnixEventPort's `onSignal()` method returns a Promise that resolves the next time the signal is delivered. When the Promise is resolved, the signal is also supposed to be blocked until `onSignal()` can be called again, so that the app cannot miss signals delivered in between.

However, the epoll/signalfd implementation had a bug where it would pull _all_ queued signals off the `signalfd` at once, only delivering the first instance of each signal number and dropping subsequent instances on the floor. That's fine for regular signals, but not RT signals.

This change fixes the bug and adds a test. Incidentally, the poll()-based implementation has been correct all along.

I don't really know how to test this since the other cmsg types are bizarre and non-portable, but they do exist.

This and many other characters are surprisingly allowed by the relevant RFCs. But it turns out we implemented the RFCs correctly, so yay.

I initially didn't read the docs carefully enough and returned a StringPtr to a locally allocated string. Whoops. Make the doc a little clearer about this.

Increase arenaSpace for emscripten builds

kj::atomicAddRef(): Fix assertion error message

 Define and implement HTTP-over-Cap'n-Proto

It seems like MSVC is generating this function in translation units where it isn't acutally called, which inadvertently causes non-RPC Cap'n Proto code to depend on kj-async.

The documentation for this method clearly says that sending the message cannot be delayed because ordering may matter. Only resolving of the returned promise can be delayed to implement flow control.

Rationale: If this were a native OS pipe, closing or aborting one end would cause the other end to throw DISCONNECTED.

Note that dropping the read end of a userland pipe is implemented in terms of aborting it, which makes it even more clear that this is a disconnect scenario.

This is needed now because http-over-capnp will index the Set-Cookie header.

This change should make it relatively safe to index Set-Cookie when using KJ HTTP.

This allows an HTTP request/response to be forwarded over Cap'n Proto RPC, multiplexed with arbitrary other RPC transactions.

This could be compared with HTTP/2, which is a binary protocol representation of HTTP that allows multiplexing. HTTP-over-Cap'n-Proto provides the same, but with some advantages inherent in leveraging Cap'n Proto:
- HTTP transactions can be multiplexed with regular Cap'n Proto RPC transactions. (While in theory you could also layer RPC on top of HTTP, as gRPC does, HTTP transactions are much heavier than basic RPC. In my opinion, layering HTTP over RPC makes much more sense because of this.)
- HTTP endpoints are object capabilities. Multiple private endpoints can be multiplexed over the same connection.
- Either end of the connection can act as the client or server, exposing endpoints to each other.
- Cap'n Proto path shortening can kick in. For instance, imagine a request that passes through several proxies, then eventually returns a large streaming response. If the proxies is each a Cap'n Proto server with a level 3 RPC implementation, and the response is simply passed through verbatim, the response stream will automatically be shortened to skip over the middleman servers. At present no Cap'n Proto implementation supports level 3, but path shortening can also apply with only level 1 RPC, if all calls proxy through a central hub process, as is often the case in multi-tenant sandboxing scenarios.

There are also disadvantages vs. HTTP/2:
- HTTP/2 is a standard. This is not.
- This protocol is not as finely optimized for the HTTP use case. It will take somewhat more bandwidth on the wire.
- No mechanism for server push has been defined, although this could be a relatively simple addition to the http-over-capnp interface definitions.
- No mechanism for stream prioritization is defined -- this would likely require new features in the Cap'n Proto RPC implementation itself.
- At present, the backpressure mechanism is naive and its performance will suffer as the network distance increases. I intend to solve this by adding better backpressure mechanisms into Cap'n Proto itself.

Shims are provided for compatibility with the KJ HTTP interfaces.

Note that Sandstorm has its own http-over-capnp protocol: https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/web-session.capnp

Sandstorm's protocol and this new one are intended for very different use cases. Sandstorm implements sandboxing of web applications on both the client and server sides. As a result, it cares deeply about the semantics of HTTP headers and how they affect the browser. This new http-over-capnp protocol is meant to be a dumb bridge that simply passes through all headers verbatim.

- Add a `size()` method.
- Add a `forEach()` that enumerates tabled headers by ID, and only uses string names for non-tabled headers.

This implementation features path-shortening through pumps. That is, if an incoming Cap'n Proto stream wraps a KJ stream which ends up pumping to an outgoing Cap'n Proto stream, the incoming stream will be redirected directly to the outgoing stream, in such a way that the RPC system can recognize and reduce the number of network hops as appropriate.

This proved tricky due to the features of KJ's `pumpTo()`, in particular:
- The caller of `pumpTo()` expects eventually to be told how many bytes were pumped (e.g. before EOF was hit).
- A pump may have a specified length limit. In this case the rest of the stream can be pumped somewhere else.
- Multiple streams can be pumped to the same destination stream -- this implies that a pump does not propagate EOF.

These requirements mean that path-shortening is not as simple as redirecting the incoming stream to the outgoing. Intsead, we must first ask the outgoing stream's server to create a "substream" object, and then redirect to that. The substream can have a length limit, swallows EOF, informs the original creator on completion, and can even redirect *back* to the original creator to allow the stream to now pump somewhere else.