The is_unmerged_loop predicate was using the "unmerged_loop_marker"
predecessor sentinel value to decide whether the merge state is an
unmerged loop header or not. However, the predecessor values were
otherwise uninitialized. This means that with some amount of bad luck,
you could get an uninitialized predecessor which happened to hold the
unmerged loop marker (it's more likely than a 1 in 2^32 chance, because
it could be left over from a previous compilation's zone).

Since we anyway now store whether a merge state is a loop header for
other reasons, we can replace the sentinel logic with predecessor count
based logic for this predicate.

Bug: v8:7700, v8:13109
Change-Id: Ibabe23feefc2bb909cf2480113300cb4757114d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807591
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82166}