Fix various other issues with monster buckets in the ItemRepository

By always enabling the debug defines in the test_itemrepository we
easily ran into all kinds of assertions. Some where wrong, but most
where at least partially correct and uncovered a wealth of connected
issues which I could not detangle from another. As such, this patch
sadly does a few things together, as otherwise the tests would always
fail. Thankfully, at the end, I managed to run not only the tests
with the debug assertions enabled, but could also parse a large
real-world application and save/load it from the cache! Previously,
both would always lead to assertions in various places.

Some of the issues that I uncovered:

- We never marked the tails of the monster buckets anywhere, meaning
  when we got an item request that fell into a bucket index that was
  merged with others to form a monster bucket we didn't detect it
  and silently corrupted the data by just writing the new item data
  into the bucket as-if it was an uninitialized empty bucket.
  this was uncovered by the DEBUG_MONSTERBUCKETS assertion at the top
  of ItemRepository::initializeBucket, which now got a more
  descriptive comment too.

  To fix this, I have introduced the new m_monsterBucketTailMarker
  list which stores a bool state for every bucket that is part of
  the tail of a monster bucket. The "main" bucket of the monster isn't
  marked therein, as we still want to access it as-if it is a normal
  bucket. Then, when we later try to find a suitable bucket to fullfil
  an item request, we skip over buckets that are marked as being part
  of a bucket tail.

- I also noticed that the m_freeSpaceBuckets list was not properly
  managed at all. Creating new buckets e.g. never put those into the
  free list! The patch here now ensures we always properly keep this
  list up to date, especially when creating new buckets or when
  merging/splitting monster buckets.

To ensure the new tail marker list is always available, and to fix
potentially old corrupted databases, the repo version is incremented
which invalidates all old caches.