Define behavior of solver when tags move in nasty ways

[sdboyer]

trafficstars

Sometimes, branches move nonlinearly (e.g. force push), and sometimes, tags get moved. It's important to define how the SourceManager handles these cases to make sure we're not missing anything.

Here is, more or less, the order of considerations:

1. Cached repos are mirrors of their upstreams - even of bad citizen changes.
2. If a bad citizen-type change occurs, we don't actually complain about it unless something in the solving process directly touches the problematic ref.
3. If we run into a bad-citizen change, and it's an improper move (e.g. force push) on a branch...well, we probably won't say anything about that. It's a branch; they move.
4. If the bad-citizen change is a tag being moved, and something was pinned to the old tag, we absolutely should push out a warning to the user strongly encouraging them to make a change, as they're in a potentially risky situation (that lock might be unfulfillable on a machine without an old cache).

Some additional safety measures can be taken - for example, setting gc.pruneExpire = never could ensure oprhaned objects aren't lost on git repositories. (I'll need to research the equivalents for hg and bzr).

[sdboyer]

this actually doesn't need to be MVP, i don't think

[sdboyer]

We really don't care about nonlinear branch moves, I don't think, so it's just tag movement that we have to worry about.

[fabulous-gopher]

This issue was moved to golang/dep#451