The linked lists of FreeLists could contain empty elements
(FreeListCategories whose `top()` is null). The code is carefuly
written so that this case won't break anything (probably just slow
things a little bit).  When `FreeList::FindNodeIn` (the fast path of
`FreeList::Allocate`) found such an empty `FreeListCategory`, it
removed it by calling `FreeList::RemoveCategory`, and looked in the
next `FreeListCategory` of the same size. However, on the slow path of
`FreeList::Allocate`, the functions that iterates the
`FreeListCategory` are `FreeList::TryFindNodeIn` and
`FreeListCategory::PickNodeFromList`, none of which removed empty
elements. Therefore, it could happen that a `FreeListCategory` "real"
first element could be used, but was never considered due to the top of
the linked list being empty. The behavior for the slow path should be
the same as for the fast path on that regard.

The problem was actually deeper than that: FreeListCategories were not
always in a consistent state, since they could have empty members. The
removal of those empty elements should be done as soon as they are
created, ie when allocating the last element.

This CL ensures that empty FreeListCategories are removed as soon as
they become empty.

Bug: v8:9329
Change-Id: Idda8096dc5978745894854a0405da59f7e8691a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648476
Commit-Queue: Darius Mercadier <dmercadier@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62058}