All tests are passing locally after fixing a GC-cycle related issue in
the io watcher that kept the wrong socket watchers alive. This should
probably be generalized to all watchers on all FFI platforms.

Attempt to fix (or workaround) test__socket.py on Windows

It runs locally for me on Win10/Py3.6 with both libev and libuv.

It had been sometimes failing since 2016-02 for 2.7 and 2016-04 for
3.5.

Here's the comment in the code indicating what I tracked down. Note
that the changes are more of a workaround than a true fix:

XXX: On Windows (at least with libev), if we have a cleanup/tearDown
method that does 'del self.listener' AND we haven't sometime
previously closed the listener (while the test body was executing) we
tend to sometimes see hangs when tests run in succession; notably
test_empty_send followed by test_makefile produces a hang in
test_makefile when it tries to read from the client_file, because the
accept() call in accept_once has not yet returned a new socket to
write to.

The cause *seems* to be that the listener socket in both tests gets
the same fileno(); or, at least, if we don't del the listener object,
we get a different fileno, and that scenario works.

Perhaps our logic is wrong in libev_vfd in the way we use
_open_osfhandle and determine we can close it?

Additional note:

Possibly libuv doesn't suffer from this since it takes the SOCKET
object directly? I didn't fully test that situation, but libuv tests
were failing and are now passing.

Add and fix test_ftplib.py and test_asyncore.py for 3.6. 

Test on 3.6.3 on Travis; appveyor was already there. 

Use setuptools to build libuv, and enable it on Windows (especially for PyPy)

Let PyPy fail on Appveyor for now. Also bump Travis PyPy to 5.9.0 because I can't reproduce the test__makefile_ref failure locally on 5.9.0. Fixes #1029.

Successful test with CPython 3.5 on Windows 10; have to elide getaddrinfo and getnameinfo because they won't link.

Tweak test for random ImportWarning from Python 3: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__

Use setuptools to build libuv. This should be much simpler, especially on windows, at the cost of manually keeping up with link arguments and file deps.

Initial libuv support

Hmm, the 32-bit builds all failed with 'The system cannot find the drive specified.' five times. Maybe it didn't like our comments?