Event Subsystem: No longer require integrators to have their own

[bradh352]

This PR implements an event thread to process all events on file descriptors registered by c-ares. Prior to this feature, integrators were required to understand the internals of c-ares and how to monitor file descriptors and timeouts and process events.

Implements OS-specific efficient polling such as epoll(), kqueue(), or IOCP, and falls back to poll() or select() if otherwise unsupported. At this point, it depends on basic threading primitives such as pthreads or windows threads.

If enabled via the ARES_OPT_EVENT_THREAD option passed to ares_init_options(), then socket callbacks cannot be used.

Fixes Bug: #611
Fix By: Brad House (@bradh352)

[bradh352]

@piscisaureus you appear to be the expert in Windows AFD and I was wondering if you'd be kind enough to answer a few questions.

I noticed in your "wepoll" you open \Device\Afd\wepoll and enqueue all IOCTL_AFD_POLL for each socket against that open handle, but in libuv, instead you created an OVERLAPPED peer socket with WSASocketW() and then register that with IOCP and submit IOCTL_AFD_POLL against that peer socket.

That said, it appears libuv has a lot of fallback handling for failures for the WSASocketW() sequence then fall back to a slow path. I'm not really seeing any fallback mechanisms in "wepoll".

I've implemented the latter (libuv) style approach in src/lib/ares_event_win32.c as I didn't really like the container_of() or CONTAINING_RECORD() approaches to determining the right address of the private per-connection data structure, as I can just register it as the CompletionKey (as a side note, I'm not sure why libuv is using CONTAINING_RECORD() instead of the CompletionKey).

The main question I have, is WSASocketW() known to fail in some circumstances? If so what are those? Is opening a handle to \Device\Afd\blah considered safer, more reliable, or more versatile in any way?

Thanks!