Modal, Alert: label modal with title contents

[RasmusKjeldgaard]

Which issue does this PR close?

This PR closes #3677 closes #3679

What is the new behavior?

Background
For all our different types of modals, we need a way to label them for assistive tech. We want to remove this burden from developers, so they do not have to re-visit every modal and apply a label.

One solution would be to use aria-labelledby as recommended for modals with visible title bars, but since IDs are scoped to the shadow root, this is not an option with ion-modal. The dialog element is within the modals shadow-root, while the title provided by us is in the light-dom, so any ID ref for the title is undefined in the dialogs tree. This is a general limitation ("feature") when working with shadow roots, and I have created a small example of this here: https://codepen.io/rasmooose/pen/dyxwWLa

Therefore we need to instead use the aria-label attribute and ensure that it is updated whenever the title changes. The most common use-case for a changing title is routed modal flows, where the same modal instance is reused for multiple views, but this could also simply be some async content.

---

We now sync the title to the ion-modal dialog elements aria-label. It is done via the modal wrapper and message state (empty state) component when used inside modals.

This ensures that a title is set across the different types of modals and also the alert.
A mutation observer or title setters are used where relevant to react to title changes and update the label of ancestor modals.

The only identified edge-case not supported by this pattern is compact modals without an empty state - in this case developers need to set the aria-label attribute themselves.

Does this PR introduce a breaking change?

• Yes
• No

Are there any additional context?

Checklist:

The following tasks should be carried out in sequence in order to follow the process of contributing correctly.

Reminders

• Make sure you have implemented tests following the guidelines in: "The good: Test".
• Make sure you have updated the cookbook with examples and showcases (for bug fixes, enhancements & new components).

Review

• Determine if your changes are a fix, feature or breaking-change, and add the matching label to your PR. If it is tooling, dependency updates or similar, add ignore-for-release.
• Do a self-review.
• Request that the changes are code-reviewed
• Request that the changes are UX reviewed (only necessary if your PR introduces visual changes)

When the pull request has been approved it will be merged to develop by Team Kirby.

[jakobe]

🥳