These will help with future PyPI discovery, and should make it clear
that Python 3.x is not (yet) supported.

- Uses /usr/bin/env so it still works in e.g. a virtualenv
- Uses python2, rather than python3 to indicate mitogen currently being
2.x only.

py_packages is not a field know by distutils or setuptools. The closest
is `py_modules`, which perhaps what the erroneus line here started as.

Fixes #43

Without this, it's possible for Waker to be start_received() after the
shutdown signal has already been sent, resulting in 5 second delay
during shutdown.

Additionally mask EBADF during os.write() to waker's write side.
Necessary since nothing synchronizes writer threads from the broker
thread during shutdown. Could be done with a lock instead, but this is
cheaper.

Can't figure out what it's supposed to do any more, and can't find a
version of Ansible before August 2016 (when I wrote that code) that
seems to need it.

Add some more mitigations to avoid sending dylibs.

By replacing pytest-capturelog with pytest-catchlog we fix one warning
that is reported by pytest:

```
venv/local/lib/python2.7/site-packages/pytest_capturelog.py:171
'pytest_runtest_makereport' hook uses deprecated __multicall__
argument

None
pytest_funcarg__caplog: declaring fixtures using "pytest_funcarg__"
prefix is deprecated and scheduled to be removed in pytest 4.0.  Please
remove the prefix and use the @pytest.fixture decorator instead.
pytest_funcarg__capturelog: declaring fixtures using
"pytest_funcarg__" prefix is deprecated and scheduled to be removed in
pytest 4.0.  Please remove the prefix and use the @pytest.fixture
decorator instead.

-- Docs: http://doc.pytest.org/en/latest/warnings.html
```

pytest-capturelog seems to be unmaintained, the bug in question
<https://bitbucket.org/memedough/pytest-capturelog/issues/6> has been
open since July 2015. pytest-catchlog is a fork of pytest-capturelog.

Now there is a separate SHUTDOWN message that relies only on being
received by the broker thread, the main thread can be hung horribly and
the process will still eventually receive a SIGTERM.