Revert of 5ab2abf7..., un-simplifying the trimming.

On MS.NET, and a stronger machine, the ShieldedDict would sometimes,
under big write load, suddenly stall, reducing from >100k writes/sec to
<10k. It turns out that the trimming simplification was to blame. As one
thread was trimming, others were writing into the Count field. The
simplified trimming would call TrimCopies on the Count every time it
would see it, while every commit on other threads would write in it. This
would mean that there would be more and more versions that the
Shielded.TrimCopies method would have to skip through, but in vain,
since the first call already trimmed what had to be trimmed in this
trimming run. At the same time, the commits were adding to the queue
for future trimming runs. When the trimming was just slow enough so
that a lot of versions and new trim-queue items are added, then the
next trimming could get even slower, and things would suddenly escalate.
A pretty interesting race condition.

Returning to the old way - first collect distinct fields for trimming, and then
trim - resolves the issue and the dictionary has stable performance again.