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.