libuv sets ref status on start; timer watchers special case start references. fixes test__queue and test__order.

libuv unrefs handles when they are started just like libev. fixes some test timeouts notably test__order.

OTOH, test__queue now fails with LoopExit in many cases (before, only
TestQueue.test_peek_empty failed with a timeout). So we must be missing
a counter subtelty.

Sadly this exposes the fact that libuv doesn't allow multiple handles
for a given poll fd. Nor does it raise clear errors until you try to
close them in an order different from the inverse of the one they were
created in. Doing so simply aborts the process when libuv realises that
the watcher it has registered is not the watcher you're closing.

This further means that multiple watchers wont' get the right set of
events delivered, I think (though most of the tests were passing until I
discovered this crash).

Sadly, libuv simply cannot be used in a child process that has fork()'d
from a parent that also used libuv. The result is a pretty quick abort()
and crash.

It *may* be possible to implement `subprocess` on top of uv_spawn (I
haven't looked into that), but things like multiprocessing and
futures.ProcessPoolExecutor would be completely broken.

Comments in commit.

fixes test__loop_callback.

The test_threading_2 failure was due to CFFI under Python 3; that combo
hadn't actually been tested before. There's a detailed comment in this
commit that explains the failure and the workaround.

All the tests pass except for
test_threading_2.ThreadJoinOnShutdown.test_3_join_in_forked_from_thread.

This is failing because threading._shutdown is failing. That in turn is
failing because threading._after_fork is getting called.

Now, threading._after_fork is *supposed to always be called*. This is
handled directly by os.fork(). But instrumentation shows that it doesn't
get called when we use the C library (and if we do call it, the test
fails), and apparently it didn't get called before the refactoring. Not
sure what's going on.

[skip ci]