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/1273095Reviewed-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}