Split the matrix computation into its own reusable workflow - #277

Prototype. A matrix becomes a collapsible group in the Actions run view only
when it sits on a job declared in the workflow the run belongs to. In the
current shape the matrix is one level down, inside reusable-testing.yml, so it
is not surfaced and all fifty legs appear as one flat list under a single "test"
header. That is why the earlier attempt to group them by moving the PHP version
into the calling job's name failed: there was no group to move it to.

Move the `prepare` job into reusable-prepare-matrix.yml and expose the two
matrices as workflow_call outputs. A package can now call that directly and run
the legs from its own top-level jobs, which puts the matrix where the run view
will group on it.

reusable-testing.yml keeps its four inputs and now delegates to the new
workflow, so every existing caller is unaffected and adoption is opt-in per
package. Verified that both shapes pass identical `with:` blocks to the called
workflows, that the public inputs are unchanged, and that the extracted matrix
logic produces byte-identical output — 41 functional and 9 unit legs on a pull
request, 51 and 12 on the schedule.

This repository's own testing.yml adopts the fanned-out shape as the reference
implementation, referring to the workflows by local path so that a pull request
here exercises its own changes rather than whatever is on main.

The cost is documented in the README rather than hidden: the fan-out is about
thirty lines in a file that is not synced, so future changes to it have to be
repeated per package. Leg names stay self-describing in both shapes, which means
the grouped view repeats the PHP version inside the group. Worth revisiting once
the grouped run can actually be seen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jy4dmjymj9VmoTBaqrV4iX

Confirmed against wp-cli/wp-cli-tests#352 that the fanned-out shape does group
the legs in the run view. What it also showed is that the leg names then repeat
their group: a group called "Behat | PHP 8.5" containing "Behat | PHP 8.5 | WP
latest | SQLite".

wordpress-develop handles this by suppressing the prefix in the called workflow
whenever the calling job already states it — its leg name only includes "PHP {0}
with" for the test-group and coverage callers, which are exactly the ones whose
job name is not "PHP {0}". Do the same, with an explicit `grouped` input rather
than inferring it from unrelated inputs.

Wrapped callers leave it at its default of false and are unaffected; their names
still have to stand on their own because their calling job is not surfaced.

The expression is written as `!grouped && <prefix> || ''` rather than the more
natural looking `grouped && '' || <prefix>`, because an empty string is falsy and
the latter would fall through to the prefix in both cases. That is the same trap
that made fetch-depth always evaluate to 1 earlier in this branch; zizmor's
unsound-ternary audit is clean on the form used here.

Noted in the README that a grouped leg name is only unique within its group, so
the back-out is to set `grouped: false` for that caller.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jy4dmjymj9VmoTBaqrV4iX