fixes bug 1052727 - Signature summary to support returning multiple reports

@AdrianGaudebert r?
cc @ossreleasefeed @rhelmer

So I thought this would be a lot easier change but as I dug in I found some really strange flaws and things that weren't testing properly. 

The new change is that you used to do this:
```python
for report_type in report_types:
    r = SignatureSummary().get(
        report_type=report_type,
        signature=signature,
        start_date=start_date, 
        ...
    )
```
Now that's going away. But is still supported out of legacy. (will file follow-up bug)
The new way of using this API is like this:
```python
r = SignatureSummary().get(
    report_types=report_types,
    signature=signature,
    start_date=start_date, 
    ...
)
```

Inside the middleware implementation it doesn't try to do anything smart. It simply loops over every `report_type in report_types` and does a SQL select for each just like before. 
The big noticable difference, that matters, in `signature_summary.py` is that it's using **one** connection for each report type and it keeps it open for each and every one. Also, I moved some pieces around but it's just for avoiding too much indentation. 

What was really hard was to fix up all the old tests. It used to be that calling `/signature_summary/` in the middleware it would return a plain list (yuck!). Now it returns something like this:
```
{"reports": {
    "uptime": [...uptime stuff...],
    "graphics": [...graphics stuff...],
    ...
}}
``` 
It used to just return `[...uptime stuff...]` or `[...graphics stuff...]`. 

And now for the really good news. I collected a bunch of signatures, cleared the cache and loaded the `/signature_summary/json_data` view. For example `'http://socorro/signature_summary/json_data?range_value=7&range_unit=days&signature=StrChrIA&version=Firefox:33.0a2&date=2014-08-13`
I did this before and after making this patch. The results are:

Before: 
https://gist.github.com/peterbe/a952e404086f42cf06fe
After:
https://gist.github.com/peterbe/26cf4d706267e9534412

**That's, on average, 5 times faster to load all the signature summary data per signature!**

Also, had I been logged in when making these, it would make the old way even slower!! because it would require one more request for each signature. 

When you click on various signatures from the "Top Crashers" you can really feel how it loads the "Signature Summary" tab much faster. 

I would put that verification in a different loop, before this main one. Reason is, if the last report_type of the list is incorrect, then you have executed a bunch of SQL queries and used some precious resources to only raise an exception. Not that I expect this to happen very often, but it seems like a better way to do this to me (first make sure you can execute all the queries, then execute them).