Allow items to be clipped by the intersection of multiple clip chains

[staktrace]

I'm not convinced this is entirely covered by #840, so I'm filing a new issue.

The scenario that we want to support is described by Markus at https://bugzilla.mozilla.org/show_bug.cgi?id=1408792#c13 - the problem is that the WR API doesn't allow us to say "this item should be clipped by the intersection of these two clip chains". We can only specify a single clip chain per item, plus a "local clip" on the item, which isn't powerful enough to support the use cases in question.

[staktrace]

/cc @mrobinson

[glennw]

Question - do we need an arbitrary number of clip chains that can be specified, or do we know / think that two would cover all use cases?

[mstange]

You can nest the example arbitrarily deeply, so I think we would need an arbitrary number.

The other way to resolve this conundrum would be to make it so that clips on a stacking context always apply to everything that's rendered by that stacking context (including the stacking context's contents). This would be closer to what Gecko is doing.
Maybe this already happens when the stacking context has a filter. I think it would have to happen at least for the blur filter.

[mrobinson]

@mstange Just to clarify, stacking contexts don't have clips. For filters, the boundaries of the filtered area are determined by the display items inside (and their respective positions).

[mrobinson]

I can understand now why we'd want to add the option to add a special clip to a stacking context.

[staktrace]

@mrobinson It would be good to prioritize fixing this, not just for correctness but also to unlock some clip optimizations on the gecko side (in that we can do a better job of deduplicating the clips we send to WR).

[staktrace]

Also for the record, doing this via clips on a stacking context always applying to their contents would work, but it would mean that we would start pushing stacking context where we weren't before, just for the sake of getting the clips working properly. This might end up being pretty heavyweight. I think from my point of view the best API would be something like a push_persistent_clip(id: ClipId) (and corresponding pop function) that work similar to the current push_clip_id function, except the provided clip gets intersected into all the things pushed inside it.