Skin extensions using "always" cannot restrict themselves to a set of actions

Description

A skin extension (JSX or SSX) whose use field is set to always is loaded on every page of the wiki, unconditionally. There is no way to say "always, but only in edit mode" or "always, but only in view mode", so a number of extensions that are only useful in one mode are downloaded in all of them.

The code already acknowledges the gap. AbstractSkinExtensionPlugin carries this comment:

// TODO Global extensions should be able to select a set of actions for which they are enabled.

Impact measured on a plain page view

On a default flavor, viewing a near-empty page issues 19 /bin/ssx/ requests and 16 /bin/jsx/ requests. Among them:

• Annotations — AnnotationCode/Style, AnnotationCode/Settings (JSX and SSX) and AnnotationCode/Script are all always, with no right or action check. /bin/jsx/AnnotationCode/Script is 27 KB and its only guard runs after it has been downloaded. It also defines xwiki-text-offset-updater on top of fast-diff and requires it immediately, which is what pulls fast-diff/diff.js (38 KB) on every page view, guests included.
• Tour — TourCode/TourJS is always, and it unconditionally issues a $.getJSON to TourCode/TourJson on any viewport wider than 768 px. That runs an XWQL query per page view; on a page with no tour the response is 12 bytes. The flavor additionally ships a wiki-wide always SSX from a content page, Tour/HomepageTour/WebHome.
• Mentions — XWiki/Mentions/MentionsMacro JSX is always, but its body is pure CKEditor configuration code, so it is only useful while editing. Its SSX is genuinely needed in view mode, but only on pages that actually contain a mention, so it belongs to the wiki macro rather than to the whole wiki.
• Refactoring — Refactoring/Code/RefactoringConfiguration SSX is always, and its entire body only hides an entry of the administration menu when the recycle bin is disabled. With the default configuration the response is effectively empty, yet it is fetched on every page of every wiki.

Two extensions that are correctly declared onDemand are nevertheless pulled eagerly, which is the same problem seen from the other end:

• XWiki/PDFExport/WebHome is pulled by its own UI extension as soon as a PDF template is configured, so a 9 KB JSX, an SSX and an eager translation REST call happen on every page view although the export modal is never opened.
• XWiki/SharePage is pulled by flamingo/menus_content.vm whenever the share menu entry exists, rather than when the share form is opened.

Suggested fix

Implement the action filter described by the TODO, so that a global extension can declare the actions it applies to. Once it exists, the extensions listed above can be narrowed down to the modes where they are useful. In the meantime the individual cases can be moved to onDemand and pulled from the macro or the sheet that actually needs them.

Worth noting for anyone looking at the wider picture: there is no bundling of skin extensions either — getImportString() emits one <link> or <script> per extension document, so each extension is a separate HTTP request.