Speedup dependency resolver by analizying fruitless branches first

[cmaglie]

This change helps not to get stuck in a loop when analyzing cases similar to #14 but with the unsuccessful branch that can not be pre-cut because buried deep in the dependency tree:

A
\__ B (1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4)
     \__ C (1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4)
          \__ D (1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4)
          \__ E (1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4)
          \__ F (1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4)
          \__ G (1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4)
          \__ H (1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4)
          \__ I (dependency not available)

BTW this change does not fix the worst case, it moves it further away, but it's still possible.
A better strategy must be implemented for more complex scenarios.

[codecov]

Codecov Report

Merging #15 (7cce8cf) into master (df298c3) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #15   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           10        10           
  Lines          815       828   +13     
=========================================
+ Hits           815       828   +13     

Impacted Files	Coverage Δ
resolver.go	100.00% <100.00%> (ø)