fix(overlay): add overlay lifecycle methods to stack management

[Westbrook]

Description

• create "Overlay Lifecycle" methods that call into the overlaid element at open and close time:
  • overlayWillOpenCallback marks the beginning of the open cycle. by default this is followed in a few short frames with the actual opening of the overlay and in this way can be seen as equivalent to an overlayOpenedCallback for most concerns)
  • overlayOpenCancelledCallback takes into account overlay content that is delayed (usually tooltips) and could have their open process cancelled.
  • overlayCloseCallback handles when the entire cycle is complete and only can occur for overlays that had not previously called overlayOpenCancelledCallback.
  • each method accept an options argument with { trigger: HTMLElement } (to support expanding to more options as needed in the future) and returns void
• leverage these lifecycle methods in the sp-tooltip element to appropriate hang content in the origin location to be used for accessibility while the actual sp-tooltip element is in "overlay" position and not accessible via IDREFs.
  • add hidden content with the sp-tooltip's textContent and appropriate aria attributes across the overlay experience to ensure that the trigger is "described by" the tooltip.
• overlay-trigger now handles an abortOverlay promise for hover-content so that in the likelihood that said content is delayed the warmup time can be cancelled appropriately.
• add testing for the above.

Alternative

Right now we dispatch sp-opened and sp-closed events on the trigger element of the overlay feature. We would be similarly served as the above were we to dispatch the same events on the content elements as well and leverage event listeners rather than direct method calls. We could place bubbles: false on one of those dispatches to prevent bubble phases on both events, but we would still have capture phases on both which means that elements that might listen to these events above might face challenges disambiguating one event from the other. In this way we could dispatch more specific events sp-opened and sp-content-opened or more specific detail packages:

{
    interaction: TriggerInteractions,
    type: 'trigger' | 'content',
    trigger: HTMLElement,
    content: HTMLElement,
}

vs:

{
    interaction: TriggerInteractions,
}

However, there is something to be said about the pseudo "privacy" of this approach, as well as its relation to the custom element and LitElement usage of lifecycle methods.

Related Issue

fixes #1078

Motivation and Context

More accessible tooltips.
More capable overlay system.
World peace?

How Has This Been Tested?

• manual with both the chrome dev tools accessibility tree and macOS Voiceover x-brower
• unit tests leveraging the accessibility tree across chromium, webkit and firefox.

Screenshots (if appropriate):

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
  • Maybe. But, I think we should keep this sort of API pseudo "private" for a little to shake out the wrinkled before documenting.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[Westbrook]

I've updated the lifecycle naming based off of some feedback from @jstoeckm both in the code and the description above.

I've also updated the overlayOpenCallback to be overlayWillOpenCallback and overlayOpenCancelledCallback to defeat the screen reader timing outline in #1078 (comment)