Load Bootstrap once per skin

[malberts]

For #70

Skins that bundle their own Bootstrap (for example Medik and Tweeki) also received
Extension:Bootstrap's copy, because BootstrapComponents loaded ext.bootstrap.styles and
ext.bootstrap.scripts unconditionally. That put two copies of Bootstrap on the page: two
stylesheets, whose cascade left stray list bullets on the skin's sidebar and dropdown menus, and
two scripts, each registering Bootstrap's document data-api, so one click was handled twice and the
skin's navbar and action dropdowns opened and immediately closed.

BootstrapComponents is the extension that pulls in Extension:Bootstrap, so it is the right place to
decide when that is needed. It now loads Extension:Bootstrap's Bootstrap only on skins that do not
provide their own (BootstrapProvider::skinProvidesBootstrap), from a BeforePageDisplay hook
where the active skin is known. On a skin that ships its own Bootstrap, nothing extra is loaded, so
there is a single copy. Extension:Bootstrap is unchanged and stays an honest, unconditional
provider.

Component initialisation goes through a small shared module (ext.bootstrapComponents.bootstrap)
that finds whichever Bootstrap is on the page: the window.bootstrap global that
Extension:Bootstrap and most Bootstrap skins expose, or the jQuery plugin bridge that some skins
register instead (a plugin's Constructor is the native component class). No skin's own module name
is referenced, the init calls read as plain Bootstrap (Carousel.getOrCreateInstance( element )),
and it runs on wikipage.content, so it also covers dynamically rendered content.

Behaviour

Bootstrap still loads on every page that renders parsed content, as before. The BeforePageDisplay
hook adds it only when the page parsed BootstrapComponents content (the same scope in which the
parser hook runs), so pages that render no wiki content, such as most special pages, are unaffected,
exactly as before.

One deliberate change: the load moved off the ParserOutput (it has to, so the decision can depend
on the skin, which the shared parser cache cannot), so api.php?action=parse no longer lists
ext.bootstrap.styles / ext.bootstrap.scripts in its module lists. Ordinary page views,
VisualEditor and live preview are unaffected, since they render on a page that already loads
Bootstrap. Only a headless consumer that renders BootstrapComponents content fetched through
action=parse, outside a page, would need to load Bootstrap itself.

Verification

Automated browser testing (Playwright) across Vector, Chameleon, Medik and Tweeki: provider skins
load a single Bootstrap, their sidebar and dropdown menus have no stray bullets, and navbar/action
dropdowns open and stay open; carousel, modal, popover, tooltip and accordion work on all four,
including through the jQuery bridge on Tweeki. A released-vs-branch comparison on Vector confirmed
the page scope matches: content pages, message-parsing special pages and Special:ExpandTemplates
load Bootstrap; chrome-only special pages do not. Unit tests cover the provider list.

_{AI-authored, Claude Code, Opus 4.8; extensively steered by @malberts across many rounds, the approach was reworked several times; diff not yet human-reviewed; verified with unit tests and automated browser testing (Playwright) across four skins plus a released-vs-branch behavioural comparison; phpcs not run locally (the repo has no phpcs setup).}