Tighten up exception handling with non-preferred bucket names

Previously, almost any exception raised could raise a misleading
WARNING/HINT message that also contained a voluminous stack trace.  It
confused me into thinking this was a crash at first (for a short
base-backup upload).

This version checks the bucket name prior to submitting it to S3, and
does not handle cases as exhaustively, but does handle the one
complaint that has occurred in practice, which is upper case bucket
names.  In this precise case the warning is displayed and is
definitely topical, and the stack trace hidden.

Conflicts:
	tests/test_s3_worker.py
Copy in and use a recent version of subprocess module

The subprocess source advertises to working all the way back to Python
2.2, so it should be a strict superset of WAL-E supported Python
versions (2.6+).

Although bugs in subprocess have been worked around before in WAL-E,
the final straw leading to this nuclear option is is issue #16327[0],
which causes file descriptor leaks within subprocess in event of fork
failure, which after the fork()-OOM-retry patch become much more
severe.

In that latter case, a vicious cycle forms wherein failed fork()s leak
resources (leaked file handles), causing the parent process to grow,
which increases the memory spike required for fork-exec, making future
forks more likely to fail.  WAL-E can die in that case from the file
descriptor leak.

[0]: http://bugs.python.org/issue16327
Enfeeble failing subprocess doctests

These seem to have specific dates and require specific error messages
from basic POSIX utilities.  This patch is split out to explicitly
document the hacks applied to subprocess.
Fix set notation use in subprocess.py

It doesn't seem like this should be committed to Python.org in a file
that claims to be 2.2 compatible.  Probably worth a bug report.