Content sources container download implemented using queues.

The main reason for the change is to support passing a generator into ContentContainer.download().  The original algorithm iterated the *requests* passed into download in several passes.  In order to iterate the *requests* once (to support generator), each requests is queued to the first source in it's list of sources that provide the requested content.  Then, when (and if) a request fails to be satisfied by a given source, it is queue to the next source (and so on ..).  The same basic algorithm but implemented using queues instead of multiple passes through the list of requests.

```
[jortel@localhost sources]$ nosetests --with-coverage --cover-package=pulp.server.content.sources
.............................................................................................
Name                                     Stmts   Miss  Cover   Missing
----------------------------------------------------------------------
pulp.server.content.sources                  2      0   100%   
pulp.server.content.sources.constants       25      0   100%   
pulp.server.content.sources.container      196      0   100%   
pulp.server.content.sources.descriptor      36      0   100%   
pulp.server.content.sources.model          170      0   100%   
----------------------------------------------------------------------
TOTAL                                      429      0   100%   
----------------------------------------------------------------------
Ran 93 tests in 0.156s

OK
```
Actually, here's an idea. It looks like ``self.in_progress`` is only accessed to determine if there are any requests in progress or not. Even the specific number doesn't seem to be important.

You could make ``self.in_progress`` a Queue object. Have the ``started`` function put any object on the queue (perhaps ``None``), and have ``finished`` take a value off the queue (and throw it away).

Any occurrence of ``len(self.in_progress) == 0`` can be replaced with ``self.in_progress.empty()``

Then instead of this ``while`` loop, you can call ``self.in_progress.join()``, which will block until there are no more requests in progress.

One thing this might not account for is if ``self.canceled`` gets set while the ``join()`` is blocking. Is that possible? If so, is it simple enough to deal with that scenario? My suspicion is that the download threads would each drain their queues, and ``self.in_progress`` would end up empty anyway.