Add a static `XWiki.widgets.Notification.show()` factory to display a notification

Current behaviour

The only way to display a notification is to construct one and drop the instance:

new XWiki.widgets.Notification(message, 'info');

This is the documented contract of the widget – its own comment in notification.js states "To display a notification, it suffices to create a new XWiki.widgets.Notification object" – and it works, because the constructor calls show() unless the inactive option is set.

A reader has to know the widget's contract to understand that the statement does anything at all. 

The SonarCloud issues

SonarCloud raises javascript:S1848 ("Objects should not be created to be dropped immediately without being used") on every such call site, currently 21 of them across 12 JavaScript files, and it is a BUG-severity rule so these count against the reliability rating and the new-code quality gate. Each one is a false positive that has to be triaged by hand, and every new call site adds another.

The 21 open javascript:S1848 issues this change could close 

Proposed improvement

Add a static factory next to the existing XWiki.widgets.Notification.textFormat and XWiki.widgets.Notification.getContainer statics:

XWiki.widgets.Notification.show = (text, type, options) => new XWiki.widgets.Notification(text, type, options);

Call sites then read:

XWiki.widgets.Notification.show(message, 'info');

Backward compatibility

Fully additive. The constructor is unchanged and keeps working, so no existing caller inside or outside the platform breaks. Extensions can feature-detect the new method the same way they already feature-detect textFormat.

Scope

Beyond adding the method, fixing the sonar warning would imply migrating the call sites that instantiate a notification purely for the side effect: 31 statements in .js files and 60 in wiki-page .xml files, 91 in total. The remaining ~179 uses of the constructor assign the instance to a variable and already read fine; they are left alone.