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.

The new `Executor` class provides an interface to run a function on some other thread's EventLoop.

`kj::getCurrentThreadExecutor()` gets a reference to this thread's executor, which can then be exposed to other threads.

When a thread requests execution of a function on another thread, the return value is returned to the requesting thread. The requesting thread may choose to wait synchronously for this return value or -- if the requesting thread has an event loop of its own -- it can get Promise for the eventual result.

Meanwhile, orthogonally, the function can either return a raw result or return a Promise; in the latter case, the Promise is resolved to completion in the executor thread and the final result is sent back to the requesting thread.

This is better than `MutexGuarded<T>::when()` in cases where the caller already has a lock -- `when()` would require unlocking, then immediately locking again (to check the predicate).

Possibly `when()` should be removed in favor of `wait()`.

This will be important in subsequent commits adding cross-thread events to EventLoop. We'll only want wait() to throw if we know no cross-thread events will ever come, but the EventPort won't know that, only the EventLoop will.

Add basic system clock APIs.

Fix filesystem API: Empty mmaps should succeed.

I had a snarky comment in the Windows code being annoyed that mapping an empty file was documented to fail... but it turns out zero-length mappings fail on Linux, too. Also my work-around on Windows didn't work (but was never tested).

This PR fixes both.

This was prompted by @KubaO observing that `capnp compile` on an empty source file failed with a cryptic mmap error.

Closes #854, @KubaO's attempt at fixing this, since the correct fix is in the filesystem API, not in the compiler.

Fixes #822

Fixes #840

Doc fix: Expand the short description of the list pointer.