Bug 1760227 [wpt PR 33225] - [block-in-inline] Fix hit-testing when block-in-inline...

Bug 1760227 [wpt PR 33225] - [block-in-inline] Fix hit-testing when block-in-inline in a culled inline, a=testonly

Automatic update from web-platform-tests
[block-in-inline] Fix hit-testing when block-in-inline in a culled inline

This is a follow up to r975579 crrev.com/c/3489020.

|NGBoxFragmentPainter::HitTestAllPhases| runs hit-testing in
phases:
1. Try `kHitTestForeground`.
2. If the result is none, try `kHitTestFloat`.
3. If the result is none, try `kHitTestChildBlockBackgrounds`.

r975579 crrev.com/c/3489020 fixed hit-testing block
backgrounds of block-in-inline by honoring the phases.
However, when block-in-inline appears inside a culled inline,
the culled inline logic consider the block-in-inline is a part
of the culled inline. This computes the culled inline as a hit
in `kHitTestForeground`, therefore we don't try lower phases
of the [painting order].

This patch changes |LayoutInline::HitTestCulledInline| to
ignore block-in-inline. By not hitting block-in-inline in the
inline `kHitTestForeground` phase, the hit-testing falls back
to `kHitTestFloat` and `kHitTestChildBlockBackgrounds` phases.

[painting order]: https://www.w3.org/TR/CSS22/zindex.html#painting-order

Bug: 1307110
Change-Id: I567c6c9b692c68ade8fb38f87c6c316930712746
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3529307
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#982110}

--

wpt-commits: 916e4e57d75fb1b1207a1148c6a32ee5dc82a2fb
wpt-pr: 33225