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.
I also do not like having the thread here. I had a version before that ran without threads, but there are issues with removing this thread. From an earlier conversation in [#2070](https://github.com/celery/celery/issues/2070) we determined the transport needs to run asynchronously. Because of a limitation in qpid.messaging there is no way to keep this asyncrhonous without the use of threading because the monitoring facilities it does provide only support blocking for asyncrhonous read methods. Furthermore it was low performing because if it did get removed we would be using a slow synchronous style I/O method.

The issue that prevents this from working without threads is that qpid.messaging does not provide an externally monitor-able file descriptor that I can register with celery AIO interface. I've raised this issue with the qpid community several times, but they are unable to provide that feature any time in the near future. Celery expects such a file descriptor for the AIO interface, so this transport code basically plays the role of the middle man, and performs an efficient blocking read on all qpid.messaging connections and tricks celery into realizing the messages have been pre-fetched and are ready to be popped from the correct qpid.messaging receiver.