Add new lifecycle features for moving dependencies around
Force unlock dependencies in Lockfile#reduce!

Previously, I attempted to write a half-assed algorithm for
recalculating the lockfile when dependencies were removed. This was
because I wanted to avoid talking to the resolver at all costs (since it
was slower than <some analogy of a slow thing here>). However, it had
bugs. A LOT of bugs. And we now have a better resolver. I could have
rewritten Lockfile#reduce!, but now we just force-unlock elements from
the graph, thus throwing it into an untrustable state. That sounds bad,
but it is actually a good thing.

By force removing elements from the graph, we ensure that a new resolver
object will be created. BUT, we still read from the graph. So this means
that existing locks will still be used.

This commit also added more debugging log output to Lockfile#reduce! by
proxy, since I needed it. It is helpful.
debiug -> debug (typo)
Check the output of the Berksfile.lock when moving a transitive dependency
Use the same version in the lifecycle feature
Don't trust top-level dependencies have been checked

This fixes a really strange bug in the lockfile where we preemptively
said a dependency was checked, but it actually was not.
Document GraphItem#to_s [ci skip]
Merge pull request #1117 from berkshelf/sethvargo/remove_dependency

Force unlock elements in the graph when reducing