Cached resolution (minigraph caching)

[Consolidated resolution](https://github.com/sbt/sbt/pull/1454) proved that avoiding work by caching is going to be faster than trying to do all the work efficiently.

![cached-resolution](https://cloud.githubusercontent.com/assets/184683/4450170/9773d7b8-4822-11e4-9342-2fb2a2e74cee.png)
(consolidated resolution)

One drawback of this approach is that it requires most subprojects to have identical dependencies graph to take advantage of the speedup.

Instead of creating an artificial graph for unique subprojects, cached resolution creates an artificial dependency graph for each direct dependency of a subproject. I'm calling them a minigraph. Minigraphs can expand to dozens of modules using stock resolution algorithm, and then saved to individual json files. Finally, these minigraphs are stitched together using the conflict resolver built into Ivy.

![cached_resolution](https://cloud.githubusercontent.com/assets/184683/4450239/52e78be8-4823-11e4-912f-c42a12bbfbaf.png)
(cached resolution)

To make sure that dynamic revisions (such as -SNAPSHOT) are handled correctly, sbt will keep an internal logical clock, which will be incremented when the user issues a command. Also these minigraphs are shared across different builds.
It's amazing how my initial impression was "why the cache/getOrElse", then I forgot `getDependencies` is super side-effecting/slow.