Debugging for a weird EPERM error in test__fileobject.py on travis with libuv; not seen locally or on appveyor [skip appveyor].

And must be close() when done. The IO watchers already required this
for libuv; doing it for everything simplifies memory management and
object lifetimes and lets us get rid of a bunch of weakref objects
with callbacks.

This is a new requirement and will only affect those that use
CFFI (e.g., PyPy) and specifically it's needed for libuv; libev
doesn't really do much with it.

Some debugging help for forgetting to close objects piggybacks on
tracemalloc on Python 3.

test_ftplib.py fails in Python 3 because of some warnings about
unclosed objects.
test__backdoor.py fails in Python 2 for the same reason.

[skip appveyor]

GEVENTSETUP_EV_VERIFY has to be set when gevent is compiled. Move it from the 'leaktest' target down to where we call develop

This lets us start using our infrastructure for flaky timeouts.

Make Timeout._start_new_or_dummy stop forcing the issue.

The failing test_telnetlib was fixed by avoiding a zero-duration timer. On libuv zero duration timers can block the event loop.

libev follows libuv by not updating the loop time in a timer by default. A Timeout that we use internally still does this though.

correct a typo in src/gevent/greenlet.py
[skip ci]

Let the Timeout class update the loop time when used internally. Otherwise, test_telnetlib.py 'hangs'. Not exactly clear why, but at a guess apparently we're not getting out of the timer callback loop.

libuv: do not update the loop time when timers are started by default. See #1057. libev might follow suite in the future.

But see the comments in the code and the comments in the issue. libuv
has very different timer behaviour than libev.

It depended on when the timer expired relative to when we intered the
loop for the first time. It could still run before our other callbacks
did if it had expired before we entered the loop.

I suppose that going to the static 'extern' functions changed the
timing of things enough that this exposed itself.

I'll need help to reproduce them.

But temporarily add some extra debugging to the makefile to see if we
get a clue.

The cpython failure in test_subprocess.py definitely began with this
branch (which doesn't make much sense). The PyPy failure was happening
long before.