Have itertools.chain() consume its inputs lazily instead of building a tuple of iterators at the outset.

didn't create, in most cases. When there are max_children handlers running, it
will still wait for any child process, not just handler processes.

new thread had started. At least on my MacBook Pro, that wound up sleeping for
a full 10ms (probably 1 jiffy). By using an Event instead, we can be absolutely
certain that the thread has started, and return more quickly (217us).

Before:
$  ./python.exe -m timeit -s 'from threading import Thread'  't = Thread(); t.start(); t.join()'
100 loops, best of 3: 10.3 msec per loop
$  ./python.exe -m timeit -s 'from threading import Thread; t = Thread()'  't.isAlive()'
1000000 loops, best of 3: 0.47 usec per loop

After:
$  ./python.exe -m timeit -s 'from threading import Thread'  't = Thread(); t.start(); t.join()'
1000 loops, best of 3: 217 usec per loop
$  ./python.exe -m timeit -s 'from threading import Thread; t = Thread()'  't.isAlive()'
1000000 loops, best of 3: 0.86 usec per loop

To be fair, the 10ms isn't CPU time, and other threads including the spawned
one get to run during it. There are also some slightly more complicated ways to
get back the .4us in isAlive() if we want.

sure all tests run even if some fail.

which forbids constructing types that have it set. The effect is to speed

  ./python.exe -m timeit -s 'import abc' -s 'class Foo(object): __metaclass__ = abc.ABCMeta' 'Foo()'

up from 2.5us to 0.201us. This fixes issue 1762.