add alert so braille users can detect events

[meganrogge]

fixes #195282

Braille users don't benefit from audio cues, so we should offer alert as a customizable / additional alternative. I have heard from users that some might use both cues and the alerts.

[hediet]

Why is this LineChanges?
I don't understand what notifyLineChanges([AccessibleNotificationEvent.Save]) would mean. Maybe that needs to be a different enum?

[hediet]

This is fishy that every LineFeature now has an event and audioCue and that the audioCue can be derived from the event.

[hediet]

@IAudioCueService private readonly audioCueService: IAudioCueService,

It is very fishy that this contribution now uses both the audioCueService and the accessibleNotificationService.

And indeed this causes bugs, as the line-feature enablement state is taken from the audio cue service. So if some audio cues are disabled, the corresponding accessibleNotificationEvent will not be sent either.

[hediet]

Except the mentioned bug (that line-based features don't send accessible notification events when the corresponding audio cue is disabled), I can see this implementation working.

However, from a software-design perspective, I think this feature should be implemented in a different way.
I don't think it makes sense to have accessible notification events and audio cues as separate systems.
This can quickly cause inconsistencies (which audio cue is tied to which accessible notification?) and is a source for bugs (like when the audio cue is used to check if something is enabled, but the accessible notification event is used to play the sound/cause the aria alert).

Rather, I'd rethink audio cues (which are already an abstract thing, decoupled from the actual sounds). I see two options:

1. Either I would extend the audio cue service to optionally do the aria alert (and extend the audio cue instances with the text to read).
2. Or I would replace audio cues with "accessible notification events" or "signals" entirely.
   Then some signal service takes care of playing the configured sounds or triggering the aria alert and computing if that signal even has any listeners.

Also, as a thought I just had, with the line features, maybe it even makes sense to distinguish event-based signals/audio-cues (such as the save-signal) from state-based signals/audio-cues (such as the current line has errors/warnings/breakpoints etc).

I'd start with 1. and would think about 2. as a separate refactoring.