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.
The notion of logical clock comes form [Lamport's time](http://en.wikipedia.org/wiki/Lamport_timestamps). Since the minigraphs are shared across different builds, I need to coordinate them somehow. The clock acts as a point in time that I can freeze the notion of dynamic dependencies during `update` on multiple-project build. State's hash would remain constant during command execution, so this avoids re-resolving dynamic dependencies. The next time the user types anything into the shell, the local clock will tick forward. If that's too trigger happy, we can later slow it down to synchronize with a wall clock (e.g. 15min) when State's hash is different.