Report raw HTTP content when handling client protocol errors in kj-http

This information is typically necessary to debug such protocol errors. However, it requires special handling, since it could contain sensitive information.

The code which has the best view on protocol errors is HttpHeaders::tryParseRequest(), which previously returned an empty Maybe<Request> on failure. This commit changes that function to return a OneOf<Request, ProtocolError>. This required some surgery in various other parts of the code to deal with the OneOf.

Add HttpServerErrorHandler interface to provide visibility and customization of protocol errors

The HttpServerErrorHandler is separate from the HttpService interface, because error-handling is more in the domain of the HttpServer, which can export multiple HttpServices (via the factory constructor overload).

I broke this while iterating on the new error handler mechanism, so here's a test.

Maybe<T> has a non-trivial destructor, but there's no point making it constexpr, but Maybe<T&> can be.

I decided that such wrapping did not make senes.

 Extend KJ event loop to support cross-thread events.

They are more efficient, and self-contained enough not to create trouble.

Also, Cygwin's pthread_rwlock implementation appears buggy. I am seeing it allow double locks from time to time.

Also required making KJ_WIN32 macros available on Cygwin.

(Cygwin allows direct calls to Win32 functions.)

I observed the cygwin async-xthread-test getting deadlocked here, and noticed the bug. However, the predicate in question was not flappy, so this doesn't really fix async-xthread-test.

A long, long time ago, an early version of the event loop code was multithread-aware and used futexes. I ripped that all out later but apparently didn't remove these includes.

The delay() here isn't long enough on Cygwin when using pipes for wakeup. Apparently, Cygwin pipes are very slow. :/

See my latest report: https://cygwin.com/ml/cygwin/2019-07/msg00052.html

We can't use signals for cross-thread wakeups on Cygwin because the same signal cannot be pending on two different threads at the same time.

So I broke down and made an implementation that uses pipes. Ugh.

Apparently, `sigprocmask()` on macOS affects all threads. You must use `pthread_sigmask()` to affect only the current thread. (To be fair, POSIX says that `sigprocmask()` has unspecified behavior in the presence of threads. However, having it affect all threads is bizarre. On Linux, it affects only the calling thread.)

Moreover, `siglongjmp()` on macOS is implemented in terms of `sigprocmask()`. Hence, `siglongjmp()` (with `true` for the second parameter) is not safe to use in a multithreaded program.

Instead, we must decompose `siglongjmp()` into its component parts, so that we can correctly use `pthread_sigmask()`.

This fixes the deadlocks on macOS.

Cygwin seems to be having an issue with this...

I guess this is particularly likely to happen when the threads are sharing a single core, which is probably common in CI services, explaining why I had trouble reproducing on my own hardware.

I should have done this a long time ago. We don't get any benefit from the parallel test runner, but we get a massive disadvantage in CI from not being able to see the logs.

* Extend the existing bidirectional cancellation thread to a three-thread case.
* Also create a three-thread case where the events actually depend on each other in a cycle.

The second new test made me realize a bigger problem: Cancellation really needs to destroy the PromiseNode in the remote thread synchronously before acknowledging, because the destructors of that PromiseNode could access objects captured from the requesting thread. So, I went ahead and fixed that.

While working on this PR, I noticed that http-socketpair-test was failing when using the poll()-based UnixEventPort. This fixes that. This is tangential to the PR, though.

I totally forgot to add wake()s in multiple spots.

This commit does not change any of the code.

A subsequent commit will take advantage of this to apply the exact same tests when an EventPort is in use.

For whatever reason, the default termination handler on my machine is no longer printing the exception's `what()` string. It just aborts. That makes debugging hard.

This also means that we can now use `noexcept` in unit tests as a way to make uncaught exceptions abort the process _without_ unwinding, which is especially useful in tests that create threads since they often deadlock during unwind waiting for the thread to finish.