deps: v8, cherry-pick 9365d09, aac2f8c, 47d34a3

  Original commit message 9365d09:

      [coverage] Rework continuation counter handling

      This changes a few bits about how continuation counters are handled.

      It introduces a new mechanism that allows removal of a continuation
      range after it has been created. If coverage is enabled, we run a first
      post-processing pass on the AST immediately after parsing, which
      removes problematic continuation ranges in two situations:

      1. nested continuation counters - only the outermost stays alive.
      2. trailing continuation counters within a block-like structure are
         removed if the containing structure itself has a continuation.

      R=bmeurer@chromium.org, jgruber@chromium.org, yangguo@chromium.org

      Bug: v8:8381, v8:8539
      Change-Id: I6bcaea5060d8c481d7bae099f6db9f993cc30ee3
      Reviewed-on: https://chromium-review.googlesource.com/c/1339119


Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58443}

  Refs: v8/v8@9365d09

  Original commit message aac2f8c:

      [coverage] Filter out singleton ranges that alias full ranges

      Block coverage is based on a system of ranges that can either have
      both a start and end position, or only a start position (so-called
      singleton ranges). When formatting coverage information, singletons
      are expanded until the end of the immediate full parent range. E.g.
      in:

      {0, 10}  // Full range.
      {5, -1}  // Singleton range.

      the singleton range is expanded to {5, 10}.

      Singletons are produced mostly for continuation counters that track
      whether we execute past a specific language construct.

      Unfortunately, continuation counters can turn up in spots that confuse
      our post-processing. For example:

      if (true) { ... block1 ... } else { ... block2 ... }

      If block1 produces a continuation counter, it could end up with the
      same start position as the else-branch counter. Since we merge
      identical blocks, the else-branch could incorrectly end up with an
      execution count of one.

      We need to avoid merging such cases. A full range should always take
      precedence over a singleton range; a singleton range should never
      expand to completely fill a full range. An additional post-processing
      pass ensures this.

      Bug: v8:8237
      Change-Id: Idb3ec7b2feddc0585313810b9c8be1e9f4ec64bf
      Reviewed-on: https://chromium-review.googlesource.com/c/1273095


Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56531}

  Refs: v8/v8@aac2f8c

  deps: V8: backport 47d34a3

  Original commit message:

      Revert "[coverage] change block range to avoid ambiguity."

      This reverts commit 471fef0469d04d7c487f3a08e81f3d77566a2f50.

      Reason for revert: A more general fix incoming at https://crrev.com/c/1273095.

      Original change's description:
      > [coverage] change block range to avoid ambiguity.
      >
      > By moving the block range end to left of closing bracket,
      > we can avoid ambiguity where an open-ended singleton range
      > could be both interpreted as inside the parent range, or
      > next to it.
      >
      > R=<U+200B>verwaest@chromium.org
      >
      > Bug: v8:8237
      > Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
      > Reviewed-on: https://chromium-review.googlesource.com/1254127


> Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#56347}

      TBR=yangguo@chromium.org,neis@chromium.org,verwaest@chromium.org

      # Not skipping CQ checks because original CL landed > 1 day ago.

      Bug: v8:8237
      Change-Id: I39310cf3c2f06a0d98ff314740aaeefbfffc0834
      Reviewed-on: https://chromium-review.googlesource.com/c/1273096


Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56513}

  Refs: https://github.com/v8/v8/commit/47d34a317e47bad86b68326607cd2e6de3901f3e

PR-URL: https://github.com/nodejs/node/pull/25429
Backport-PR-URL: https://github.com/nodejs/node/pull/25728


Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

Reviewed-By: Anna Henningsen <anna@addaleax.net>