[PATCH resend] churn: use ui.progress instead of --progress

[Eric Eisner]

> A little late on this, but I think I'd prefer 'changes' in instead of
> 'churning changes' for the item, since the former would use much less
> space next to the progress bar, and is more consistent with other uses
> of the progress API.

I was going off of the precedent I saw in "bundle changes," "looking
for similarities," etc. But I see the argument for a one-word
standard.

> Also, why the state dict when all it seems to store is a count?
> Shouldn't that be an integer? (disclaimer: I'm going off the unidiff
> here, with minimal familiarity with the code in question).

The progress code was in an inner function which could not modify an
integer in the outer scope. I was just lazy and didn't change the
existing structure.