WebKit export of https://bugs.webkit.org/show_bug.cgi?id=321397 - #64184

WebKit export from bug: [block-in-inline] Only a relatively positioned inline offsets its out-of-flow children by the position of its line

[block-in-inline] Only a relatively positioned inline offsets its out-of-flow children by the position of its line

An out-of-flow box whose containing block is an inline box is laid out against the nearest non-anonymous
block, so the distance from that block to the inline's own first fragment has to be added back.
RenderInline::offsetForInFlowPositionedInline is what returns it, taking the inline box's logicalTop, and
all four of its callers ask for it only when the inline is in-flow positioned. An inline is the containing
block for other reasons too, a filter among them, and in those cases the offset was dropped.

An anonymous block around the inline hid this. The wrapper is a RenderBox, so its own topLeftLocationOffset
carries the distance up the box chain in offsetFromContainer, and the inline sits at the top of the
wrapper's first line, which leaves the half-leading at most to add. With a block level box on a line there
is no wrapper: the inline's parent is the container itself, a RenderInline contributes no location offset
of its own, and the whole distance down to the line is left to offsetForInFlowPositionedInline.

Ask whether the inline is the containing block rather than whether it is in-flow positioned. For a
RenderInline canContainAbsolutelyPositionedObjects covers the fixed position case as well, since the
willChange term of each only applies to a RenderBlock, leaving mayContainOutOfFlowPositionedObjects and a
non-static position.

WebKit-Bug: https://bugs.webkit.org/show_bug.cgi?id=321397
WebKit-Canonical-Link: https://commits.webkit.org/318897@main