The script compilation cache contains weak pointers to Script objects as
its keys. When doing a rehashing operation, any hash table needs the
ability to get the hash code for every entry in the table. However, if
the weak pointer was cleared from a key, there is no longer any way to
get the hash code for that entry.

In https://crrev.com/c/3597106 , I attempted to solve this problem by
deleting all entries whose keys contain cleared weak pointers prior to
rehashing, but the implementation has a bug: when resizing, the new
table is allocated after deleting the entries with cleared keys, so if
that allocation triggers a GC, the table can once again have entries
with cleared keys.

This could be solved in a variety of ways, such as:

1. Iterate the entries again and delete those with cleared keys, after
   allocating the new table but before calling Rehash() to copy data
   into that new table. This means we can't directly use
   HashTable::EnsureCapacity, which normally does both the allocation
   and the rehashing.
2. Return a bogus hash code for entries whose keys contain cleared weak
   pointers. This is simple but risks poor distribution of data after
   rehashing.
3. Implement custom rehashing which can avoid copying entries with
   cleared keys, rather than reusing the rehashing implementation from
   HashTable.
4. Include the hash value in every key, so a consistent hash value is
   available even after the weak Script pointer has been cleared.

The fourth option sounds like the lowest risk to me, so this change
implements that option.

Bug: v8:12808
Change-Id: I6b19b9c8af67dcfc31b74842ba581dd141e18845
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3654413Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80637}