Managing resolve history

Dependencies are resolved by an ordered list of resolvers. These resolvers have different behaviors today; proposed modifications shown in italics :

("Reads resolve history" refers to whether resolve.history is used to filter versions when finding a match. "Writes resolve history" indicates whether the entry for the found module is updated in resolve.history.)

The first hit "wins." This behavior forms the basis of our fix strategy (fixes are placed into the private repository) and module debugging (modules can be checked out into the workspace).

After much discussion about the depth of the rollback queue, it seems that one level is sufficient. Any more changes are generally accompanied by other changes (e.g. ivy.xml, code changes to react), so rollback is only part of the story. Rollback should not be confused with application checkpoint/restore.

Regarding "Checks version," if the version doesn't satisfy the pattern in ivy.xml, then we would just continue to the next resolver. The user could check the results at the end with zero version. It would help if the output of zero version included the resolver corresponding to each resolved dependency.