If multiple isolates were involved, we did not always hit the breakpoint
reliably in all isolates.

This CL fixes this flake this via two changes:

1. Remove breakpoint info when tiering up.
   If we keep the breakpoint information, a second isolate that later
   sets the same breakpoint will see that the breakpoint already exists,
   and will not set it again, even though the code containing the
   breakpoint has been replaced at that point.
   This fixes a flake in the debug/wasm/breakpoints test.

2. Don't overwrite code with breakpoints by default "tiered down" code.
   This is achieved by introducing another state in the {ForDebugging}
   enum which marks that code contains breakpoints. Otherwise it could
   happen that two isolates start tiering down (both recompiling missing
   functions in Liftoff), one isolate finishes and immediately sets a
   breakpoint, then the other isolates finishes and overwrites the code
   with breakpoints by the usual {kForDebugging} code.
   Setting breakpoints is synchronized already, so overwriting
   breakpoint code with other breakpoint code is always safe.

R=thibaudm@chromium.org

Bug: v8:10611, v8:10359
Change-Id: I171d86b110a54f9eb5e4c3fa35108638904212e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316080
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69088}