Adds a test case that exercises the multiple-repository -SNAPSHOT issue. #1514

* Create a project "common" which publishes a "bad" artifact.
* Resolve project "dependent" which resolves the "bad" artifact into the cache.
* Publish a new "common" snapshot to a diffferent repository (publishLocal)
* Attempt to build the new project, leading to issues.
Minimizing scripted repro
Fixes #1514, #321. Fixes -SNAPSHOT issue by re-implemeting ChainResolver.

Adds `lastestSnapshots` flag to `updateOptions`, which controls the behavior of the chained resolver. Up until 0.13.6, sbt was picking the first `-SNAPSHOT` revision it found along the chain. When  is enabled (default: ), it will look into all resolvers on the chain, and compare them using the publish date.
The tradeoff is probably a longer resolution time if you have many remote repositories on the build or you live away from the severs. So here's how to disable it:

    updateOptions := updateOptions.value.withLatestSnapshots(false)

Ivy by default uses latest-revision as the latest strategy. This strategy I don't think takes in account for the possibility that a changing revision may exist in multiple repositories/resolvers with having identical version number like 0.1.0-SNAPSHOT.
The implementation is a bit hacky, but I think it attacks the core of this problem.
Special treatment for a special resolver: inter-project
Using iterators
Merge pull request #1520 from sbt/fix/1514

Fixes #1514, #321. Fixes -SNAPSHOT issue by re-implemeting ChainResolver