Fix connection event error handling.

Commit 86a99c6b999671ed444711139db1937617e802a0 changed the way we
handle connection events to protect against spurious event loop
callbacks. Unfortunately, it turns out that calling connect() twice on
the same socket results in different behaviors depending on the platform
(even though it seems well defined in POSIX). On Windows this resulted
in the connection handling code being unable to react to connection
errors (such as connection refused), always hitting the timeout; on
Linux this resulted in spurious error messages about connect() returning
success.

In POSIX and on Linux, using connect() on a socket where the previous
attempt failed will attempt to connect again, resulting in unnecessary
network activity. Using getsockopt(SO_ERROR) before connect() solves
that, but introduces a race condition if a connection failure happens
between the two calls.

For this reason, this commit switches from connect() to a zero-sized
send() call, which is more consistent (though not completely, see the
truth table in the comments) and simpler to use for that purpose. Note
that Windows explictly support empty send() calls; POSIX says nothing
on the subject, but testing shows it works at least on Linux.

(Surprisingly enough, Windows seems more POSIX-compliant than Linux on
this one!)
Use native Windows events for the event loop.

This commit changes the event loop to use WSAEventSelect() and
WSAWaitForMultipleEvents() on Windows. This paves the way for making the
event loop more flexible on Windows by introducing the required
infrastructure to make the event loop wait on any Win32 event.

This commit only affects the internal implementation of the event
module. Externally visible behavior remains strictly unchanged (for
now).
Make the event loop expose a Windows event interface.

This allows event loop users to specify Win32 events to wait on,
thus making the event loop more flexible.
Use a Windows event to stop tinc when running as a service.

Currently, when the tinc service handler callback (which runs in a
separate thread) receives a service shutdown request, it calls
event_exit() to request the event loop to exit.

This approach has a few issues:

 - The event loop will only notice the exit request when the next event
   fires. This slows down tinc service shutdown. In some extreme cases
   (DeviceStandby enabled, long PingTimeout and no connections),
   shutdown can take ages.

 - Strictly speaking, because of the absence of memory barriers, there
   is no guarantee that the event loop will even notice an exit request
   coming from another thread. I suppose marking the "running" variable
   as "volatile" is supposed to alleviate that, but it's unclear whether
   that provides any guarantees with modern systems and compilers.

This commit fixes the issue by leveraging the new event loop Windows
interface, using a custom Windows event that is manually set when
shutdown is requested.
Remove the TAP-Win32 reader thread.

tinc is using a separate thread to read from the TAP device on Windows.
The rationale was that the notification mechanism for packets arriving
on the virtual network device is based on Win32 events, and the event
loop did not support listening to these events.

Thanks to recent improvements, this event loop limitation has been
lifted. Therefore we can get rid of the separate thread and simply add
the Win32 "incoming packet" event to the event loop, just like a socket.
The result is cleaner code that's easier to reason about.
Merge branch 'winevents-clean' of https://github.com/dechamps/tinc into 1.1
Give getsockopt() a reference to a socklen_t.