Keep m_nextBucketHash alive across convertMonsterBucket changes

When a bucket is part of a hash clash it may have entries in the
m_nextBucketHash. When we then later convert the bucket from/to
a monster bucket, we need to keep that data alive, otherwise we
run into the infamous `bucketForIndex(bucketNumber)->noNextBuckets()`
assertion.

The expanded unit test easily triggers this behavior which was
previously not covered: we now also test situations with two
monster buckets, and three items instead of just two. Furthermore,
we test all possible permutations, which runs quickly and previously
always triggered the assertion.

This patch here fixes that situation, by keeping the m_nextBucketHash
data alive across the convertMonsterBucket changes.

FIXED-IN: 5.11.230400
BUG: 272408