Release: build-time extension selection, and measure the Phase 2.5 acceptance test

[PurHur]

Adds --only= / --without= to the registry generator — and then runs the acceptance test the
plan names, which changes what this phase is for.

The measurement

RELEASE-PLAN Phase 2.5 states: "a script that never calls into an extension pays nothing for it —
not in link time, not in binary size, not in startup." I regenerated the registry with 6 extensions
instead of 76 and rebuilt hello world:

registry	hello-world binary	cold build
all 76 extensions	17,148,584 B	6 s
6 extensions	17,148,944 B	6 s

The minimal build is 360 bytes larger. No saving at all.

Two further measurements explain it:

• nm finds zero curl/mongodb/snmp/ldap symbols in a hello-world binary built with the
  full 76-extension registry — unused extensions are never linked in;
• a script that does call an extension grows the binary ~572 KB (bcadd) — so demand-driven
  linking already works.

The binary is dominated by .text at ~15 MB: runtime and compiler core, not extensions.

What this means for the phase

Phase 2.5 cannot be justified by user binary size or user build time — that benefit already
exists. The plan sizes the phase at "37% fewer files", which implies a proportional user-visible
win. Measured, it is not there to collect.

What survives, and is worth doing:

1. Extensibility — "a new extension is a directory, not a core edit". Delivered by Release: generate the extension load list instead of hardcoding it (Phase 2.5) #24418.
2. The compiler's own build cost — the 6,519-file spine as a single translation unit, which is
   the multi-hour gen-0 problem. That is the real cost centre, and it is what the per-module TU split
   addresses.

I would rather report this now than spend weeks moving module boundaries for a saving that does not
exist. The plan is updated in place so the next person does not re-derive it.

The selection mechanism

--only= / --without=, with a dependency closure so a selected extension never silently loses
one:

$ php script/generate-extension-registry.php --only=standard,spl,dom
generate-extension-registry: kept for declared dependencies: libxml
generate-extension-registry: wrote lib/ExtensionRegistry.php (4 extensions)

Selection is at generation time, not runtime, and that is forced by the architecture: the
registry emits literal new expressions that the AOT compiler resolves statically, so a referenced
module is compiled in regardless of any runtime filter. Dropping the cost means dropping the
reference.

Identity is the ext/ directory, never getExtensionName() — 20 modules report 'standard'
(#24418).

Gate

No behaviour change: lib/ExtensionRegistry.php regenerates identical (76 extensions).

generate-extension-registry --check   ok (76 extensions)
check-extension-dependencies          ok — 6 extensions, 7 edges
ExtensionRegistryOrderTest            OK (2 tests, 231 assertions)
aot-smoke                             8/8
cold-build-check                      ok — 6s

No sweep run: this changes a generator and a doc, and the generated file is byte-identical to the
committed one.

Aside, not chased

The bcadd probe binary produced no output where it should print 3.3. I could not judge that
against Zend — this image's PHP has no bcmath, so php and bin/vm.php both fatal with "Call to
undefined function bcadd()" while the compiler implements its own. Flagging rather than filing,
since the corpus cannot gate a function Zend does not have here.