Fixes #1104

Be more careful about issuing the SSL warning on Py2.

Also some other doc updates.

[skip ci]

Fixes #1108.

Update c-ares to 1.14. Fixes #1105.

Support GEVENT_RESOLVER_SERVERS for configuring dnspython nameservers.

Also allow this for ares, and deprecate the GEVENTARES_SERVERS environment variable.

Fixes #1103.

ccache saves us time on compiling, but not linking. The difference is unlikely to be significant for test purposes.

Make socket.sendall() fast on PyPy3: 60MB/s -> 600MB/s

I see in on OS X even without gevent involved. I see it with gevent involved both on the sendall branch and the master branch. I see it on Travis (now) with the sendall patch.
I don't know if it's been seen before the sendall patch on Travis---flaky builds tend to get rerun. None of the other SSL tests are failing, though, and the pypy version of test_ssl.py notes that test_handshake has been removed from CPython altogether.
It looks like it's very dependent on buffering and things like that.

TestEtcHosts round-robin failures also seen on appveyor with the system resolver---because we're not using the local system hosts file.

Share the chunking code between Python 2 and 3.

Also get the tests passing (read: skip a bunch) with 5.10.1 on OS X,
which is apparently less well tested than Linux.

We don't test pypy3 on appveyor, so:

[skip appveyor]

Simplify libev default loop handling and let it regenerate itself.

Don't let destroying the default C loop from two different Python loo…

Don't let destroying the default C loop from two different Python loop objects crash the process. Fixes #1098

Take a whack at using ccache to speed up builds on CI.

[skip ci]

Centralize configuration in a ``gevent.config`` object.

Extra tests for _config. Fix a long-standing bug where package paths in import names did not clean up after themselves.

Before I realized that was the root cause, I refactored to avoid
starting the hub greenlet *at all*, and that also fixed the problem.

The problem was that some versions of CPython using the libev-cext
loop (and only that one) would crash garbage collecting a
greenlet (presumably the hub greenlet, which was attached to a
destroyed loop):

0   libsystem_kernel.dylib        	0x00007fff66455e3e __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff66594150 pthread_kill + 333
2   libsystem_c.dylib             	0x00007fff663648fe raise + 26
3   libsystem_platform.dylib      	0x00007fff66587f5a _sigtramp + 26
4   ???                           	000000000000000000 0 + 0
5   greenlet.cpython-35m-darwin.so	0x000000010d76b297 green_clear + 183
6   org.python.python             	0x000000010c707e0c collect + 1824
7   org.python.python             	0x000000010c7076e3 _PyGC_CollectNoFail + 43
8   org.python.python             	0x000000010c6e81d4 PyImport_Cleanup + 968
9   org.python.python             	0x000000010c6f1b49 Py_Finalize + 92
10  org.python.python             	0x000000010c6f20d5 Py_Exit + 13
11  org.python.python             	0x000000010c6f4631 handle_system_exit + 320
12  org.python.python             	0x000000010c6f42a1 PyErr_PrintEx + 42

We should take a look at that and see if we can do something more graceful.

The gevent.select.poll object must keep a tighter handle on the lifetime of io watchers it spawns. Previously they were leaking if not unregistered, which some callers fail to do --- looking at you, dnspython.