Release: declare extension dependencies and default-enabled on Module (Phase 2.5)

[PurHur]

Next increment of Phase 2.5, after the measurement in #24285.

The blocker this removes

Module declares no dependencies and no default-enabled flag. So the extension set cannot be
selected per build, and the load order exists only as a hand-maintained list in
Runtime::loadCoreModules() where the constraints are real but implicit.

What this adds

Two declarations, with defaults in ModuleAbstract that preserve current behaviour exactly:

getExtensionDependencies(): list<string>   // default []     — ordering constraints, today implicit
isDefaultEnabled(): bool                   // default true   — all 76 load unconditionally now

Safe to add to the interface: all 76 ext/*/Module.php extend ModuleAbstract, and it is the only
implementor, so nothing needs updating.

Declaring the libxml family

php-src ext/dom, simplexml, xml, xmlreader, xmlwriter build on ext/libxml; xsl
additionally on dom:

dom, simplexml, xml, xmlreader, xmlwriter  ->  libxml
xsl                                        ->  libxml, dom

These are exactly the constraints the hardcoded order already satisfies — the point is to make them
checkable rather than remembered.

A declaration nobody verifies is worse than none

It reads as authoritative while being free to drift. script/check-extension-dependencies.php
asserts every declared dependency exists, is loaded, and loads before its dependent. It reorders
nothing — proving the declarations describe reality is the precondition for later deriving the
order from them.

Validated in both directions:

as declared                        ok — 6 extensions, 7 edges, all satisfied by the load order
with dom -> xsl (xsl loads later)  FAILED: dom (load #6) declares dependency "xsl"
                                           but xsl loads later at #7          exit 1

Deliberately not done yet

Nothing consumes isDefaultEnabled(). Runtime::loadCoreModules() is untouched — the 76 hardcoded
loads are still there, in the same order.

That is on purpose: the loop instruction for this work is to prove a generated order is identical to
the hardcoded one before anything becomes selectable, and the declarations have to exist and be
verified first. Making the set selectable in the same change would mean shipping an unverified
reordering of the thing every extension depends on.

Gate

Touches lib/Module.php and lib/ModuleAbstract.php, which every extension implements. Branch vs a
clean master checkout, run sequentially, both cold, each sweep allowed to complete before
diffing:

	branch	master
cold aot-smoke	8/8	8/8
VM --repeat 2	110/110, exit 0	110/110, exit 0
AOT --repeat 3	18 failing	18 failing

regressions (branch-only): NONE
fixed (master-only)      : NONE