Pulls in patches from V8 (52e2b5, 512175, aac2f8, 9365d09, 2d08967)
which address a variety of coverage bugs, bringing Node v10 coverage
to parity with Node v11.

  Original commit message:

    [coverage] Extend SourceRangeAstVisitor for throw statements

    The SourceRangeAstVisitor has custom logic for blocks ending with a
    statement that has a continuation range. In these cases, the trailing
    continuation is removed which makes the reported coverage ranges a bit
    nicer.

    throw Error('foo') consists of an ExpressionStatement, with a
    Throw expression stored within the statement. The source range itself
    is stored with the Throw, not the statement.

    We now properly extract the correct AST node for trailing throw
    statements.

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

  Bug: v8:8691
  Change-Id: Ibcbab79fbe54719a8993045040349c863b139011
  Reviewed-on: https://chromium-review.googlesource.com/c/1480632
  Commit-Queue: Georg Neis <neis@chromium.org>
  Reviewed-by: Georg Neis <neis@chromium.org>
  Reviewed-by: Jakob Gruber <jgruber@chromium.org>
  Cr-Commit-Position: refs/heads/master@{#59936}

  Refs: v8/v8@2d08967

  Original commit message:

    [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:

    [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

  Original commit message:

    [ast] Introduce ZonePtrList<T> typedef for ZoneList<T*>.

    This is a preliminary step before changing the way we store zone pointers
    in the zones.

    Bug: v8:7903, v8:7754
    Change-Id: I1e1af1823766c888ee0f8fe190f205f5b7e21973
    Reviewed-on: https://chromium-review.googlesource.com/1118887
    Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
    Reviewed-by: Marja Hölttä <marja@chromium.org>
    Reviewed-by: Camillo Bruni <cbruni@chromium.org>
    Commit-Queue: Igor Sheludko <ishell@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#54193}

  Refs: v8/v8@512175a

  Original commit message:

    [explicit isolates] Replace every Handle(T*) in parsing/

    Replace all but one Handle<T*>(T*) calls with ones that explicitly pass
    in an Isolate.

    Requires plumbing Isolate* through several Parser functions which
    previously avoided it because of worries about accessing the heap off
    the main thread. In all off-main-thread cases, isolate will be nullptr
    and every such function asserts with:
    DCHECK_EQ(parsing_on_main_thread_, isolate != nullptr);

    Also deletes unused function ParseInfo::ReopenHandlesInNewHandleScope.

    Bug: v8:7786
    Change-Id: I3dd9c49dcde49fdbcb684ba73f47a30d00fc495e
    Reviewed-on: https://chromium-review.googlesource.com/1087272
    Commit-Queue: Dan Elphick <delphick@chromium.org>
    Reviewed-by: Toon Verwaest <verwaest@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#53820}

  Refs: v8/v8@52e2b5a

PR-URL: #26579
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Shelley Vohr <codebytere@gmail.com>
Reviewed-By: Guy Bedford <guybedford@gmail.com>
Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com>