CSS highlight painting: no OffsetInContainerNode for generated text

CL:3793072 fixed a bug where we treated marker-based highlights as if
they applied to soft hyphens (and other fragments with generated text)
in a text node, so we stopped rendering incorrectly or crashing in
these situations.

CL:3804327 added an optimisation for marker-based highlights, which
involved converting a pair of canonical text offsets to DOM offsets.
This is an operation that doesn’t make sense for generated text, but
we did it regardless of whether the fragment was generated text.

Usually that’s harmless (albeit a waste of time), because CL:3793072
ensures that we don’t pass any markers to ComputeEdges in this case,
so the variables will never get read anyway.

But if there’s an atomic inline nearby, such as an <img> or <button>,
then trying to do GetLastPosition(0) and GetFirstPosition(1) for the
soft hyphen might return beforeAnchor and afterAnchor for the atomic
inline, both of which violate the assertion in OffsetInContainerNode
that the positions are of the offsetInAnchor kind.

For example, in <https://bucket.daz.cat/work/igalia/0/59.html>...

<img><s>aaaaaaaaaaaaa&#xAD;a
<script>
    document.body.style.width = 0;
    document.execCommand("selectall");
</script>

...the text that those operations are run against is effectively...

    [OBJ]aaaaaaaaaaaaa[SHY]a
    U+FFFC            U+00AD

...where [OBJ] represents the atomic inline, rather than the text for
the generated hyphen, yielding beforeAnchor IMG and afterAnchor IMG.

Fixed: 1367860
Change-Id: I0b033a15a58fed661f5ebc9981a726b0850029fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3944075
Commit-Queue: Delan Azabani <dazabani@igalia.com>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1057858}