Add inflation support to OpenSpending.
This can cause serious performance issues since inflation is done on the fly and for large datasets with more than 10000 drilldown results a single requests can take around a half a minute to inflate.
The reason this cannot be done in the database and just use a database call to do the aggregation is that inflation data is severly lacking. We don't know if we can do inflation at the time of the database insert. If inflation data then gets better we would have to rerun across all datasets to update and we do not know when inflation data is updated since that's a different project. But still, we would have to do inflation on the fly (since we don't know what to inflate to) but the inflation would be simpler and could be done closer to the dataset.

For this reason the inflation isn't "advertised" (and not tested) anywhere but this allows others to step in and try to implement a better solution. At least now we a better separation between the cache and the aggregation itself.
Improve inflation performance. Added requirements.

Culprit for bad performance found. The economics package was slow. Updated to a faster version (and added requirements).
Added tests. FIXTURE update.

Tests were added and some changes made to both entry view and the aggregation as a consequence.
An inflation test needed a fixture update so that the dataset would have a territory assigned to it (in order to be able to do inflation).
Added possibility of different date formats.
Also beefed up the inflation method so that it contains reusable code (and created two helper function, one for date parsing the other for a single country retrieval).
Cleaned up unused modules in entry and aggregation (their use has been moved to the helper library)
Merge pull request #688 from openspending/feature/inflation-adjustment

Feature/inflation adjustment