feat: composer-based sets + register as rector-extension

[bbrala]

What

Two related changes that let Rector configure Drupal deprecation fixes from the installed drupal/core version.

1. Composer-based sets (DrupalSetProvider)

A SetProviderInterface exposing the per-minor deprecation and breaking configs as ComposerTriggeredSets keyed on drupal/core. Enable with:

return RectorConfig::configure()
    ->withSetProviders(\DrupalRector\Set\DrupalSetProvider::class)
    ->withComposerBased(drupal: true);

• Cumulative-downward via ^version: a site on 11.4 loads 11.0→11.4 and never a future minor — inherently BC-safe (only rules for deprecations that are live on the installed core). Verified incl. dev/beta core.
• The exact-version match makes the breaking sets safe to fold into the same drupal group.
• The PHPUnit bootstrap is supplied by a dedicated config/drupal-bootstrap.php set, matched once per major (drupal/core ^10.0 / ^11.0). The per-minor deprecation configs don't register it (only the aggregated *-all-deprecations.php sets do), and composer-based selection loads the per-minor configs directly — so the bootstrap is registered separately. Kept apart on purpose: the bootstrap throws without a Drupal install, and composer-based sets only ever load when drupal/core is present, so the throw can never fire here.
• Covers drupal/core 10.0–10.3 and 11.0–11.4.

2. Register as a rector-extension (progressive enhancement)

type: rector-extension + extra.rector.includes ships config/extension.php, which supplies sensible Drupal defaults (file extensions, autoloading, the upgrade_status skip, phpstan-drupal). It loads before the project's rector.php, so the project config always wins.

The bundled rector.php template is left unchanged / self-sufficient on purpose — see the testing note below.

Why the template wasn't slimmed (empirical finding)

I tested whether the auto-config loads in a real consumer (scratch project, sentinel in config/extension.php, ran rector --dry-run):

Consumer setup	extension.php auto-loaded?
rector/rector + drupal-rector	❌ No
+ rector/extension-installer	✅ Yes

So the auto-config only activates when the consumer has rector/extension-installer (rector/rector doesn't pull it in, and Composer silently skips plugins not in allow-plugins). Slimming the template would therefore risk silently dropping .module/.theme coverage for projects without the installer. The template stays the reliable source of truth; the extension is a bonus for projects that have the installer.

The same test caught a bug: DrupalFinderComposerRuntime::getDrupalRoot() throws (Package "drupal/core" is not installed) rather than returning null, so the lookup is now guarded with InstalledVersions::isInstalled('drupal/core') and re-verified to not throw on non-Drupal projects.

Upstream dependency

withComposerBased(drupal: true) needs Rector core to ship SetGroup::DRUPAL + the drupal: toggle — rectorphp/rector-src#8041. Until then the provider is dormant. Plan per @TomasVotruba: get the provider into main, then kick off testing upstream.

Verification

• Full PHPStan clean, full unit suite green (659 tests), composer validate OK.
• DrupalSetProviderTest: 8 tests / 82 assertions incl. the cumulative-matching matrix (deprecation + breaking + bootstrap) and the no-drupal/core case.
• Auto-config load behaviour + the non-Drupal no-throw path verified by hand in a scratch consumer project.

[bbrala]

Initial exploration, some issues need examination, especially the rector.php, but think this is 90%

[TomasVotruba]

I've added few comments. Looks very good to me 👍