fix(notifications): Improved notification exceptions

[nickvergessen]

Summary

Currently all methods in the notification space throw \InvalidArgumentExceptions. The problem is that there are nested calls which make it impossible to handle errors correctly or to notify wrong/invalid notifiers properly.

E.g. an app calls INotification::setLink() with an invalid value in it's INotifier::prepare(). The INotification will throw and it can go unnoticed by the INotifier as it's not meant to throw. However the IManager only sees that INotifier threw the exception and that is currently meant to be the case when the INotifier does not want to handle the INotification, so the IManager will think no one wanted to handle the notification although the respective one just had "an" error from any level. Similar problems often appear when activities are put into notifications as both providers work based on \InvalidArgumentException so none of those knows whether activity or notifications was failing actually.

This PR introduces dedicated exceptions which allow us to log them if they happened while not being expected. For the moment \InvalidArgumentException is still allowed to be thrown, and only logged on debug level, but the lib/private/Notification will only throw the new exceptions (which all extend the generic \InvalidArgumentException to keep compatibility.

• IncompleteNotificationException - is thrown by IApp::notify when a required field was not set
• IncompleteParsedNotificationException - is thrown by INotifier::prepare when it's IManager and a required field was not set during the rendering
• InvalidValueException - is thrown by IAction::set* and INotification::set* when setting an invalid value (e.g. empty link, missing rich-object parameter, ...)
• UnknownNotificationException - should be thrown by INotifier::prepare when the notification is not handled by this notifier

Companion / Sample PRs

• techdebt(exceptions): Migrate to new exceptions notifications#1882
• fix(developers): Document new notification exceptions documentation#11729

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[bigcat88]

looks good