[Feat]: Support custom boundaries element in overlay-trigger

[dialupdev]

Code of conduct

• I agree to follow this project's code of conduct.

Impacted component(s)

overlay-trigger

Description of the requested feature

I would to set both the position and width of my popover relative to an element besides the trigger element. In other words, I want to select a specific element from the DOM to use as my "boundaries element".

Here's my example. In this scenario, I want the sp-popover to be contained within the pink box. I also want the width of the popover to match the box. I want the pink box to define the boundaries of the popover.
https://studio.webcomponents.dev/edit/GnpL4UwD0h9BAbqV9DOf/src/index.ts?p=stories

Mockups or screenshots

What I get:

What I want:

Implementation notes or ideas

@pinkhominid mentioned to me that Popper has a preventOverflow plugin that may address this case.
https://popper.js.org/docs/v2/modifiers/prevent-overflow/

Also, in React Spectrum we had a boundariesElement prop that provided this behavior.

[pinkhominid]

Seems SWC is now using floating-ui (successor to popper). The equivalent plugin/middleware is called detectOverflow.

[Westbrook]

After the new Overlay API ships (currently scheduled for July 2023 🤞🏼) we'll have more room to look into contexts like this. Taking into account the <sp-overlay> element, would you prefer an API for this surfaced something specifically support boundaries, e.g.:

<sp-overlay
    .triggerElement=${triggerEl}
    .boundaryElement=${boundaryEl}
></sp-overlay>

Or something that more generically supported the diverse Floating UI middleware ecosystem, like:

<sp-overlay
    .triggerElement=${triggerEl}
    .floatingUIMiddleware=${additionalMiddleware}
></sp-overlay>

In the case of the middleware approach, how might you control order of provided middle ware in relation to the default middleware we already leverage?

Alternative

Also, which we'd need to do some additional testing with the fallback system, in most cases use of contain: strict; on the parent element will now contain the child overlay stricly to its bounds. Much less JS to muck around with in that case, but contain: strict does sometimes have unintended side effects, even if one of them is generally a performance boost for the consuming application.

[Westbrook]

Usage of contain: strict in this context seems like the correct path forward for now. If you feel this doesn't satisfy the needs of your work, feel free to share additional use case data in a new issues.