[Task](ui): create a first version of NotificationManager

[franzheidl]

WIP

Task Description

Create a first version of a NotificationManager component using Sonner.

Objectives

• Have a first working version of a Notification Manager
• Validate our below considerations and assumptions on using Sonner as a basis for our notification system as a basis for an informed decision whether to move on with Sonner or not

Considerations And Assumptions

The current general assumption is we can wrap Sonner and let it do most of the heavy lifting, but can add functionality that is specific to Juno and our needs in terms of customization.

• We create a NotificationManager component that wraps Sonner
• Our API receives and forwards props to Sonner
• Our API may recieve additional props that we control/manage
• We can use our own Toast component instead of Sonner's inbuilt ones and pass our component to Sonner to render (There is also a headless mode in Sonner that may be working as an alternative: Sonner documentation - Styling
• We control the DOM mount point where we let Sonner render our Toast notifications, so we can guarantee notifications always render on top of other content (that may be rendered in a portal using PortalProvider already.
• We can render semantic notifications according to Juno semantics
• We can render dismissable and non-dismissable (timed) notifications
• We can customize the duration of a notification
• We can show multiple notifications with identical or overlapping durations
• We can handle (or at least have an idea and a technical concept) for handling "overflow" situations when there are more notifications visible at a single point in time than fit on the current screen
• We have event handlers that fire when a) a notification is shown, and b) a notification is dismissed or disappears
• We can target any existing message in order to update/delete it

Implementation Tasks/Notes

• Define a mount point / second portal root that we exclusively use to render notifications after our universal portal root in AppShell
• Validate whether we can use our existing PortalProvider to render this mount point, too (we have only ever used a single instance so we should validate there are no conflicts or undesirable side effects)
• Map existing props of Toast to Sonner props, define API in detail incl. sensible/opinionated defaults
• When mapping/forwarding props and types, make sure we do not create a hard dependency to Sonner (see hew we handle forwarding interfasces of external libraries here: feat(ui): decouple interfaces from external interfaces #1445)
• When NotificationManager manages the full lifecycle of each notification, we can and should remove the (rudimentary) lifecycle props and logic inside Toast. Toast should become a fully logic-less component when using NotificationManager.

Out Of Scope

• Notification history / storing notifications beyond their expiry

Additional Information And Resources

• Sonner documentation – Getting started
• Rendering custom elements in Sonner