HighlightOverlayPainting: fix buffer confusion and clamping bugs

[chromium-wpt-export-bot]

Custom highlights and marker-based highlights are defined in terms of
DOM ranges in a Text node. Generated text either has no Text node or
does not derive its content from the text node, so the active ranges
of these highlights should be ignored, but we fail to do so for soft
hyphens (a kind of generated text).

On its own, this can cause spurious paints of things like highlight
backgrounds near soft hyphens if [0,1) is highlighted.

CL:3720688 also changes the logic of ComputeParts, requiring parts to
be added to the result outside the main loop if originating fragment
offsets extend past the first or last highlight edges. For example,
with an originating fragment [a,b) and first highlight edge [c,d)
where a<c<b<d, we add originating part [a,c) before the main loop.

But if a<b<c<d, for example, the originating part should be [a,b), not
[a,c), and this can cause the failures in bug 1346809 and bug 1346810.

This patch fixes both bugs by ignoring marker-based highlight ranges
for all generated text including soft hyphens (like we already do for
ellipsis) and clamping parts to the originating fragment even when
they are added outside the main loop.

Fixed: 1346810, 1346809
Change-Id: If3369bfb1a44ebce190db8fa8477065eeba00d86
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3793072
Reviewed-by: Philip Rogers <pdr@chromium.org>
Commit-Queue: Delan Azabani <dazabani@igalia.com>
Cr-Commit-Position: refs/heads/main@{#1030541}

[wpt-pr-bot]

The review process for this patch is being conducted in the Chromium project.