More Vagrantfile manipulation
Removed errant Vagrant config; breaking on modern Vagrant
Add leiningen to the Vagrant provisioning
All aggregations now use map-reduce

This requires us to compute aggregations behind the scenes and cache
their results. When computed, we give the result like normal. When not
yet computed, we give the user an indication that it is currently
processing.

From an architectual angle, this changes the application significantly.
We now have another process running watching for new map-reduce jobs
that need to be done. These jobs are stored in Mongo, and atomically
claimed, so any app server can claim it. (`lein run` starts a worker to
claim and work these jobs.) The aggregation framework in Mongo is not
used at all, which gives us more flexibility.

Is this perfect? No way. Two queries with the exact same information
might have different cache keys because they are addressed differently
(`GROUP BY state, county` as opposed to `GROUP BY county, state` for
example.) We also do not give an indication of how backed up jobs are,
and we don't have a way to expire caches that are not being used. Those
can all come later, though: for now, this makes aggregations work.

Added ability to generate map-reduce for any aggregation

WIP Added query key generation

Fix project.clj to exclude duplicate libraries

Also only compile main.clj when making an uberjar

WIP Add query caching and cache workers

This is still a work-in-progress. It works via REPL, but needs the
front-end built out. Aggregations are now done asynchronously by putting
them as jobs into a Mongo collection. You must start a separate worker
to work the jobs. When the jobs are done, the aggregation is available.

WIP Removed circular dependency

Now I need to go hog-wild refactoring

WIP fixed all tests

Added some front-end behavior for computing aggregations.
Merge pull request #95 from cndreisbach/cache-aggs

All aggregations now use map-reduce