Fix race condition that ignores MAX_TRANSPORTS limit

The check for MAX_TRANSPORTS compares to the size of the list of
transports. Transports get added to that list after they have been
created. But creating a new Transport requires yielding, during which
some other callback chain may do run the comparison between
MAX_TRANSPORTS and the list of transports.

This happens for example when you kick off a bunch of requests to Riak,
all at the same time. Then each will request will pass through the
MAX_TRANSPORTS check, yield for a while and then append the new
Transport to the list. Each yield makes it possible for then next
request to pass the MAX_TRANSPORTS check, since the list is still
unmodified. The test in test_pbc_transport.py tests exactly this
scenario.

It would probably be a good idea to change the exception type that is
being raised to something more specific than Exception. How about
TooManyTransports?
Ensure transports get recycled even on __put failures

Previously the call to StatefulTransport.setIdle was skipped if an error
occurred while working with the transport in __put. This would cause the
too many transports error to occur prematurely. The fix is to use
finally to assure that setIdle is always called.
Make StatefulTransport a contextmanager and use it to handle setting transports idle after use
Remove transports from the list if they could not be set up properly, to avoid leaking transports in the face of MAX_TRANSPORTS
Do not remove transports from the list on defer.returnValue, only for actual exceptions
Merge pull request #26 from wrapp/fix-max-transports

Fix max transports