Initial sketch of bug #282, aggregate cell data export.

I believe this mostly accomplishes the "hourly exports of changes to Cell table" issue, in very broad brush strokes. I haven't managed to test it against S3 live yet and I expect the fields will change some and possibly need preprocessing before export, but I'm posting this for feedback / review now.
Would you mind rewriting this without using the ORM? And batching it up by maybe 10k rows at a time?

Similar to what I did in https://github.com/mozilla/ichnaea/blob/master/ichnaea/backup/tasks.py#L153.

If we use the ORM, it means it'll load all 1.7 million rows from the DB at once, instantiate a Cell object for each row and put it in a session cache. That's a sure way to cause a memory spike. I'd rather get 10k rows, create a simple dict for each and use a single csv.writerows call to write all 10k dicts into the file at once (avoiding a Python method call for each item). Then grab the next 10k batch and repeat until there's no more results from the DB.

For the S3 backup job (writing 1 million rows at a time), this approach cut down the time to less than half, so I'd expect similar savings here.