[FEATURE] Provision functional test instances in composer mode

[bmack]

Adds composer mode to functional test instances. Today every instance is a classic
mode installation, even though composer mode is what nearly every project runs, so a
whole installation layout goes untested.

TYPO3_TESTING_INSTANCE_MODE=composer

Classic mode stays the default. The mode is part of the instance identifier, so a test
case's classic and composer instances never collide.

This replaces the stacked version

An earlier form of this work sat on top of #740 and needed its configuration-keyed
instance sharing. It does not any more. This branch applies to main on its own,
keeps getInstanceIdentifier() / getInstancePath() static exactly as they are today,
and introduces no breaking change — it is a plain [FEATURE].

That reordering is backed by a measurement rather than a preference. One chunk of the
TYPO3 core functional corpus (2117 tests), four arms, same machine:

	instance sharing on	sharing off
classic	160 s	207 s ← behaviour today
composer	113 s	134 s ← this PR

Composer mode without any instance sharing is faster than classic mode with it.
Sharing is worth a further ~16 %; composer mode itself is worth 35 %. So the sharing
mechanism is an optimisation on top, not a prerequisite, and it should be reviewed on
its own merits instead of blocking this.

How a composer mode instance is built

An instance is not its own composer installation. One shared installation containing
every system extension and every fixture extension is built once per run, and each
instance borrows its vendor tree and package artifact by symlink:

<instance>/vendor          -> <shared>/vendor
<instance>/public/_assets  -> <shared>/public/_assets
<instance>/config/system   own configuration
<instance>/public          own document root, fileadmin, typo3temp/assets
<instance>/var             own caches and logs

Per test case only the active package set differs, expressed by narrowing the artifact
in memory. A real installation per test configuration measures ~3.4 s, which across the
~142 distinct extension sets in core would cost more than this saves — though that
trade-off is worth revisiting, see below.

Classes are deliberately not loaded from the shared installation. The root
autoloader already maps every system extension and every fixture extension, so no second
autoloader is registered and no second copy of any third-party package is loaded.

What to look at

Most of the diff is mechanism. Two things deserve real scrutiny:

1. ComposerModeInstance::createPackageCache() — the narrowing. It hands the package
   manager every installed package while marking only some active. In a real composer
   installation installed and active are always the same set; there is no
   installed-but-inactive state. This is the one place the model departs from reality,
   and the direction of travel is to replace it with one real installation per extension
   set (measured: ~3.4 s each, ~1.8 MB of distinct bytes per set, the third-party tree
   being byte-identical across all of them).

2. SystemEnvironmentBuilder::determineCurrentScript() — on the CLI, composer mode
   reports the console binary as the entry script, because in a real installation it sits
   outside the document root. Functional tests are CLI processes simulating web requests,
   and NormalizedParams derives the site URL by subtracting the entry script's directory
   from the request. Left alone it subtracted typo3/sysext/core/bin/, the site path
   collapsed to an empty string, and every generated link silently lost its leading slash.

Everything else in the commit message is a bug that was hit on the way, each of which
failed far from its cause.

Verification

Both modes on the same corpus chunk, run back to back:

classic   2117 tests, 9088 assertions, 0 failures
composer  2117 tests, 9087 assertions, 0 failures, 1 skip

The full corpus has been run in both modes against all four DBMS with matching test
counts. CGL, lint, PHPStan and the unit suite are green locally.

Core needs a companion patch for tests that assume the classic layout; it is prepared and
waits on this.