✨ `<Dialog>`Add support for nested dialogs

[far-fetched]

Summary

As react and vue packages support nested dialogs, we should introduce the same concept.

example in react

The concept assumes that a parent dialog cannot be closed when at least one child dialog is opened. By clicking outside (ESC, on overlay) we only close the dialog which was opened lastly (leaf).

Detailed design

To achieve this goal, we need sort of counter / state in each dialog, which will keep track of information that at least one children dialog is opened. For communication between parent - child, vue uses concept of inject/provider, link.
In practice they don't have to pass explicitly properties to child component in template.
As in ember we don't have similar mechanism, and we would like to keep headless API as much unified as possible, I propose to use yield emberism. We can yield another value from <Dialog> component, e.g. Nested and then we can pass this.element to its child. Example:

{{yield (hash
   isOpen=@isOpen
   onClose=@onClose
   Overlay=(
    component "dialog/-overlay"
    ...
   )
   ...       
   Nested=(component "dialog" parentDialog=this)
)}}

then nested dialog use:

<Dialog
      @isOpen={{state.isOpen}}
      @onClose={{set state.isOpen false}}
      as |dialog|
 >
  Parent dialog
  <dialog.Nested>
     child dialog
  </dialog.Nested>
</Dialog>

Drawbacks

API is not 100% match, compare to react and vue where they used just <Dialog> inside another <Dialog>

Alternatives

I was thinking about service injected to all dialogs, then when a component is mounted, the dialog is registered in service. Each time when new dialog is registered, the service iterates on opened dialogs and checks relationship parent - child. Open question is: as long as we use portals (dialogs are render as siblings) we cannot rely on DOM nodes, native events for checking parent - child. @achambers you said about some solution for this problem - I cannot remember details - can you remind me ?

@GavinJoyce @alexlafroscia
Would be wonderful to see your voices here.

[alexlafroscia]

I was thinking about service injected to all dialogs, then when a component is mounted, the dialog is registered in service.

I think that this would be the way to go. We can use a service to store a stack of open Dialog components that is pushed to/popped from when Dialog components are mounted/unmounted. We know that a given Dialog is the "active" one if it's at the head of the stack; not being the active one will require disabling the focus trap, among other things. I think I saw a library that implements a tracked Stack class... I'll have to try to find it!

The issue that I see with yielding a Nested component is that most of the ways I would see nesting of dialogs happening, one instance won't actually know about another. I could see a component that happens to use a modal itself being rendered inside of another modal, where the "inner" and "outer" aren't connected in any way.

I am quite curious about what a good solution around providing the information to the template about whether the Dialog is active or not...

Since the React and Vue implementations don't do anything here, maybe we shouldn't either, even though we could? I would rather not provide an API initially and later introduce something than introduce something up front that we ultimately regret. I think leaning on the behavior of the official API, if in doubt, is a good idea.