Qpid Transport Support

This PR adds support for Qpid as a valid transport type for Kombu, and includes code, unit tests, docstrings, doc changes, and dependency updates.  This is very functional transport; it has been heavily tested with Celery, supports Celery events, and supports SSL.  This is being used in the upcoming release of [Pulp](http://www.pulpproject.org/).

Issues related to this code can be routed to me for bugfix and troubleshooting.

## The code
The bulk of the code itself is contained in the kombu.transport.qpid module.

NOTE: The code currently still does monkey patching of qpid.messaging.  Current versions of qpid.messaging that are out in the wild (pypi, rhel6, fedora, etc) are missing two important patches, [QPID-5637](https://issues.apache.org/jira/browse/QPID-5637) and [QPID-5557](https://issues.apache.org/jira/browse/QPID-5557).  Those patches have been accepted upstream, but not all places that provide Qpid bits contain those patches. This codebase introduces those patches at runtime, and eventually will be removed. It is safe to patch any version of Qpid 0.18+, and is safe to apply to an already patched installation.

The monkey patching has been tested currently to work with clients using 0.22, 0.24, and 0.26 versions of qpid.messaging, so it should produce the expected behavior no matter what version of tools it is patching.  The patching has been tested against the versions currently on Pypi.

The code is flake8 compliant.  You should be able to run everything as described on [this celery page](http://celery.readthedocs.org/en/latest/contributing.html#pyflakes-pep8) and it should look clean.

## Unit Tests
The unit tests are all located in the kombu.tests.transport.test_qpid module. You can run all just these new tests using:

```nosetests --with-coverage --cover-html -v kombu.tests.transport.test_qpid```

To get any continuous integration environments to run these unit tests, you'll need to install the dependencies.  Please install the dependencies in the CI environment by running:

```pip install qpid-tools qpid-python```

## The Docs
The code itself contains a huge number of docstrings.  They follow the syntax expectations of Kombu/Celery (line width, strict PEP8, etc).

The more general documentation has been updated in two important ways.

1.  The transport has its own section which is partially from the docstrings.   This contains important things like instructions on how to download dependencies.

2.  Updates to things that are no longer true.  For instance the docs use to say things like "only rabbitMQ supports SSL" which is no longer true.

You can build the docs using [these instructions](http://celery.readthedocs.org/en/latest/contributing.html#building-the-documentation).

You also should build the API reference since most of the docs live in there.  You can follow [these instructions](http://celery.readthedocs.org/en/latest/contributing.html#api-reference)

## Dependencies
This library relies on the pure-python packages named 'qpidtoollibs' and 'qpid.messaging'.  Kombu expects all pure python dependencies to be put onto pypi, and they can be "bundled" into Kombu as a group of optional dependencies.

The files introduced have all imports guarded against ImportError Exceptions so that you can import any file without installing the dependencies, and you'll encounter no Exceptions.

qpidtoollibs is currently published on pypi at version 0.26 [here](https://pypi.python.org/pypi/qpid-tools).
qpid.messaging is currently published on pypi at version 0.26 [here](https://pypi.python.org/pypi/qpid-python).

A bundle in Kombu has been created called 'qpid' which should allow someone to install the bundle using kombu[qpid].  The docs also explain how to do this.
Right, but it's not really being asynchronous at this point.  It's a nice hack, but threads are the reason we changed to async I/O in the first place.  We had to downgrade the other transports using threads to experimental/unsupported status so people are aware that it's not viable for production. Being slow is better than being unreliable.

Maybe the python qpid team should prioritize better, there are very few messaging use cases that does not involve async I/O in some way.