HSH_Purge() suffers from a problem when there are more objcores on a given
objhead than we can hold temporary references for on the available
workspace, and multiple purges for the same objhead are issued at the same
time.

The previous algorithm would use a flag on the objcores (OC_F_PURGED) in
order to keep track of how far in the list we had gotten. This becomes a
problem when multiple threads are purging the same objhead at the same
time. When a new purge is started, the flags would be reset, which would
cause any existing purge thread to restart. If a steady stream of purges
for a given objhead is issued and enough objcores are present, none would
finish.

This rework uses OC references in the list as bookmarks, in order to know
how far into the list we were when releasing the mutex partway through and
want to resume again. This relies on the list not being reordered while we
are not holding the mutex. The only place where that happens is in
HSH_Unbusy(), where an OC_F_BUSY OC is moved first in the list. This does
not cause problems because we skip OC_F_BUSY OCs.

The OC_F_PURGED flag is removed as it is no longer needed.

The existing r02372.vtc test case exercises this code.