'bzr revert' shouldn't be much slower than 'bzr status'

[John A Meinel]

Thinking about 'bzr revert' it really just walks the tree finding what has been changed, and then replaces it with different content.
However, in the gcc-linaro tree with a reasonable sized merge, it takes 'bzr st' only 2s, but 'bzr revert' takes 16s.

I'm guessing the issue is that 'bzr revert' is doing something like building up a map of all entries in the tree, rather than starting with just the changed files, and then going from there.
We've spent a lot of time making 'iter_changes' fast, we should see if we can build revert on top of it.