Auto merge of #4782 - aidanhs:aphs-dont-incorrectly-compute-cur, r=alexcrichton

Auto merge of #4782 - aidanhs:aphs-dont-incorrectly-compute-cur, r=alexcrichton

Don't incorrectly compute cur from binary heap

In the resolver, [`cur`](https://github.com/rust-lang/cargo/blob/0.23.0/src/cargo/core/resolver/mod.rs#L624) indicates how far through a 'deps frame' the resolver is, i.e. it indicates you're on the nth dep for a particular parent.

In 2015, [this refactoring commit](https://github.com/rust-lang/cargo/commit/502fa5b60a46a2349155562dcd7522ea56d338a7) made the value of `cur` be computed from the top of `remaining_deps`, a stack.

In 2016, [this commit](https://github.com/rust-lang/cargo/commit/4ec278feff81c8cbb92e37ea3dc6811f62351c7f) changed `remaining_deps` to be a binary heap to optimize cargo to choose the 'most constrained' dependencies first. Unfortunately, this means that you can no longer compute `cur`, because the relevant dep frame may not be at the 'top'. The result is that `cur` has been pretty arbitrary for about a year.

Is this a problem? `cur` is only used for debugging printouts so no...but it can underflow, panicking in debug mode! This PR stops incorrectly computing `cur`, storing it instead. It also enables overflow checking in Cargo in release mode for extra sanity checking - this (minor) bug would likely have been caught long ago and the opportunity to flush out other bugs in code that doesn't look arithmetic heavy seems like a good idea.