Just semaphores and mutexes thus far.

We don't have to worry about races because this is just a hint: we still call read() eventually.

The primary function is to check for races. The secondary function is to measure performance.

We don't have to worry about synchronization here because
wine_ntoskrnl_main_loop() is only ever called from one thread per winedevice
process.

This lets drivers like mountmgr finally work, and so winecfg can open the
Drives tab.

This, or something like this, should go upstream. This is invalid behaviour.

I originally had this return STATUS_USER_APC, but that isn't correct. The
server code here is a bit confusing, but only the thread that waits *during*
the suspend should receive STATUS_USER_APC (and I imagine that it really
should receive STATUS_KERNEL_APC instead). The thread that is suspended
should just keep on waiting.

Besides, we could be suspended for reasons other than to deliver a system
APC.

Some server calls pass an event handle, most notably asyncs. We need to be
able to handle these correctly. Accordingly we pass them along to esync if
it turns out the underlying object is actually an esync object.

In an ideal world we'd just convert all instances of events on the server
side to use esyncs instead. But we want to keep esync perfectly configurable,
so this is how we do it.

We still need this, since there are some events which the server signals.

This lets system processes shut down.

The code here is sort of self-explanatory, but since I split it up over
several patches I'll provide a quick explanation. The basic principle is
that we can create an eventfd descriptor for any synchronizable handle, and
signal it on the server side whenever a wakeup would be triggered. This means
not only that we can wait simultaneously on esync primitives and on other
primitives, but that we can do it all in "user-mode", i.e. without having to
make a server call.

With this patch we break waiting on svcctl.exe.