Fix second simultaneous read (parallel paramiko issue)

https://github.com/eventlet/eventlet/issues/94

Because of the way paramiko utilises a client thread to manage its
communication, it's not been compatible with eventlet when run in
parallel.

It's not the only place these problems would arise.

This stemmed from the reuse of a fileno by the underlying OS.
Because listeners are registered against this descriptor, it would
be possible for old listeners to receive events destined for newer
descriptors; occasionally code would attempt to utilise the new
descriptor from a different greenlet, giving rise to the 'second
simultaneous read' problem.

Whenever a Python object is created to wrap one of these filenos,
we now signal the hub in order that it can correctly obsolete
extant listeners against that fileno. This is a fairly tricky
operation, due to the way that listeners' threads are interleaved
with the hub's operation - there are a number of small fixes here
to defend against one listener from effectively obsoleting another
when an event is pending against it.
hubs: defang after remove; related to second simultaneous read issue

https://github.com/eventlet/eventlet/issues/94

We have to defang the listener after removing it from the hub

Otherwise we never actaully remove it from the hub and get a return of the
second simultanous read.

This should fix this issue.

Turn off __builtin__ monkey patching by default

The reason is that eventlet.greenio.GreenPipe tries to
adapt an original file f, and performs the following check
isinstance(f, file) f is an original file object with file
is now our file method. This fails causing TypeError

nova-api exercises this

Fix up zmq to use the extended add signature

Having heard no problems relating eventlet and zmq,
I'm not going to dive in and drop random pataches against
it. If the 'Second simultaneous *er' crops up against
zmw then we at least now have the machinery to
address it.
0.15.1 release
Bump version to 0.16.0.dev
Fix octal literal
wsgi: Support optional headers w/ "100 Continue" responses

Since WSGI is all about a single response to a single
request, in order for servers to process a PUT as a
single HTTP request and at the same time pass **hints**
back to the client (for example, a payload type that the
server can accept, or to inform the client that the server
expects to receive payload metadata at the end of the
payload transfer, etc), "100 Continue" response headers
is pretty much only place to add these hints.

This is consistent with **RFC2616, section 10.1**:

10.1 Informational 1xx

This class of status code indicates a provisional response,
consisting only of the **Status-Line** and **optional
headers**, and is terminated by an empty line.

Openstack Swift has an immediate use case for this feature
where the object server will use an
"Accept-Payload-Footer: 1" like header to hint the proxy
server to send a payload footer after it has finished
transmitting the payload (for sending metadata for an
erasure coded or encrypted payload, enforcing end-to-end
Etag checks, etc).

Addresses eventlet issue/enhancement #126

Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>
PEP-8 fixes; six.next for Python3 compatibility