Cache the last updated time

We make multiple calls to this function during the /_status/data-sets
request. Given these classes only exist for the duration of a request
are then destroyed there should be no issue caching the time.
Batch the aggregation of last updated times

The majority of the time spent responding to /_status/data-sets was
spent making connections to mongodb and making a query to get the latest
_timestamp from each collection.

This reduces the time spent significantly by opening one connection and
grabbing all of the most recent _timestamps together.
Ensure _timestamp index on all collections

The majority of the operations done on our collections revolve around
_timestamp so it would make sense to index on this field. This is
especially useful for working out which data sets are out of date as we
always want the latest piece of data by _timestamp.
Migrate mocked batch test to integration test

In order to fully test whether batching last update works it should
really test against mongo.

There is some pretty weird looking comparison due to there being a few
100 microsecond deviation between the time I wrote into mongo and the
time that was extracted out. I've copied and pasted a failed run with
direct comparison below:

```
FAIL:
tests.core.storage.test_mongo.TestMongoStorageEngine.test_batch_last_updated
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/var/apps/backdrop/venv/local/lib/python2.7/site-packages/nose/case.py",
line 197, in runTest
    self.test(*self.arg)
  File "/var/apps/backdrop/tests/core/storage/test_mongo.py", line 47,
in test_batch_last_updated
    assert_that(data_set.get_last_updated(), is_(timestamp))
AssertionError:
Expected: <2014-11-19 10:16:24.772844+00:00>
     but: was <2014-11-19 10:16:24.772000+00:00>
```

I would hypothesis that this is down to the difference between the
underlying representation used to store the datetimes, but I haven't had
the time to look deeply into it.
Merge pull request #373 from alphagov/perf/data-set-status

Perf/data set status
find out scope of problem
more scope
working update script
tidy up removal script

why does data_sets_that_may_intentionally_miss_proper_ids disappear on
second run?
not explaining where these go