Read atomic write pipe buffer size from system configuration in piper.py

Conflicts:
	wal_e/piper.py
Alphabetize import
Redo questionable the non-blocking-pipe I/O routines

There are a few reasons to revisit this code.

Most distressingly is this:

    buf = StringIO(data)

    while bytes_written < bytes_total:
        try:
            # self._fp.write() doesn't return anything, so use
            # os.write.
            bytes_written += os.write(self._fp.fileno(),
                                      buf.read(PIPE_BUF_BYTES))
        except IOError, ex:
            if ex[0] != errno.EAGAIN:
                raise
            sys.exc_clear()

In particular, the cursor-advancing side effect of "buf.read" wrapped
inside a loop that might retry in event of receiving EAGAIN from an
"os.write".  It has now been re-spelled to avoid this.

Also changed is catching EnvironmentError rather than IOError, because
of a report from Art Fedorov <artemf@mail.ru> on Macintosh that came
from an OSError which is not caught and retried when it possesses the
errno EAGAIN as one might hope.

Also, the prior code tended to call gevent.socket.wait_read and
gevent.socket.wait_write too often, which may be vastly increasing the
number of system calls.  Now those are only called when EAGAIN is
encountered.

Finally, I wonder of the possibility of mistaken increments on the
cursor on the CStringIO object above caused some of the reported
Macintosh deadlock problems, solved by reading the atomic pipe buffer
size from the operating system (see
0dd95420f354b4656d4b7ce5b1ba1720405b908c).  If so, there may be a new
opportunity to use larger buffer sizes and reduce overhead.

Conflicts:
	wal_e/piper.py