Extract the PHPUnit adapter into a dedicated repository

[fain182]

Context

The PHPUnit integration currently lives inside the main repository, in src/PHPUnit/ArchRuleCheckerConstraintAdapter.php (plus the test helper tests/E2E/PHPUnit/ArchRuleTestCase.php). It's a thin adapter that wraps the Runner into a PHPUnit\Framework\Constraint\Constraint, so that architectural rules can be asserted directly inside a PHPUnit suite instead of through the CLI.

The fact that PHPUnit is only a dev-dependency is already a bit of a stretch today: the class extends PHPUnit\Framework\Constraint\Constraint, which is not guaranteed to be available at runtime (see the @psalm-suppress UndefinedClass and the comment in the file).

Proposal

Move the PHPUnit adapter to a separate repository (e.g. phparkitect/phpunit) that depends on phparkitect/phparkitect.

Motivation

• Dedicated documentation — the integration would get its own README and examples, instead of being a barely visible detail in the main repo.
• Visibility into real usage — a separate package makes it measurable (downloads, issues, stars) how much the adapter is actually used. Today that's impossible to tell.
• A life of its own — it could evolve independently (support for multiple PHPUnit versions, more assertions/helpers) or, if unused, be deprecated without touching the core.
• Cleaner dependencies — it removes a (dev) dependency on the PHPUnit framework from the core, clarifying the boundary between the analysis tool and the test-runner integration.

Points to evaluate

• Name/namespace of the new package and a deprecation strategy for Arkitect\PHPUnit\* in the current repo (BC break for existing users).
• How to keep the two repos aligned across versions (compatibility matrix).
• Whether to move the related E2E tests as well.

[fain182]

Decision: extract, with removal from the core as the actual goal.

The reason isn't packaging hygiene, it's the design philosophy: "ideally there is one way to do each thing, so users are never slowed down by choosing between options." The PHPUnit adapter is a second way to run the same checks, so it falls under that rule rather than under the one exception (expressions with a different focus).

This is already causing concrete confusion: mixed examples online mean code generators produce phparkitect.php files built around PHPUnit assertions instead of the CLI. Real usage, on the other hand, is largely invisible — most consumers are closed source; GitHub code search returns 8 hits for ArchRuleCheckerConstraintAdapter and 7 for assertArchRule. Extracting rather than deleting keeps the door open: if the interest is real, it will show up as issues and PRs on the new repo.