instantiating a reactor leaks file descriptors/handles by way of the wakers

[radix]

On posix reactors, a waker is instantiated and file descriptors are set up when the reactor is instantiated. In order to make reactors usable in an isolated way reasonably, these file descriptors must be cleaned up. By default, most file descriptors are cleaned up when the reactor is stopped, but the waker is explicitly left out for probably rather stupid reasons (so the reactor can be restarted; but this can be facilitated in a better way). Here's the proposed changes:

• Waker should be installed when run() is called (or perhaps specifically startRunning), instead of when the reactor is instantiated.
• Waker should be removed when reactor is stopped (probably "after", "shutdown"). There are some trivially tricky issues involved with this; the trigger for removing the waker MUST be added before we fire the "run" event, to deal with cases where reactor.callWhenRunning(reactor.stop) are used.
• If we move waker installation to startRunning instead of instantiation, that means threads cannot be initialized properly until startRunning, either. When threads are initialized, the threaded resolver is installed. That means if we make this change, the behavior of reactor.resolve before reactor.run is called will change so it blocks. I can't currently think of a reason that this would be bad, but it might be.
• There may be other similar issues to the resolve() issue.

[exarkun]

As of #733, there are multiple wakers on some reactors. We should be sure to clean them all up when we fix this.

[exarkun]

(In [28513]) Branching to 'cleanup-waker-3063'

[itamarst]

(In [33908]) Branching to 'cleanup-waker-3063-2'