[Sets] Drop per-version composer-triggered sets already covered by composer-based set

[TomasVotruba]

The Symfony sets were registered twice: once per version as ComposerTriggeredSets, once as composer-based.php. I verified the overlap mechanically — across all 208 triggered sets in Symfony3SetProvider–Symfony8SetProvider and TwigSetProvider, 0 rules were missing from the matching composer-based set. Every one of them was a duplicate.

So the per-version registrations go, and only the composer-based sets stay.

 final class Symfony8SetProvider implements SetProviderInterface
 {
     public function provide(): array
     {
-        return [
-            new ComposerTriggeredSet(
-                SetGroup::SYMFONY,
-                'symfony/uid',
-                '8.1',
-                __DIR__ . '/../../../config/sets/symfony/symfony8/symfony81/symfony81-uid.php'
-            ),
-            // ... 5 more
-        ];
+        return [];
     }
 }

The trigger package list goes too

SymfonySetProvider gated composer-based.php behind a hand-maintained list of 52 packages and versions. That list duplicated, one level up, what each rule already declares for itself:

public function provideComposerPackageConstraint(): ComposerPackageConstraint
{
    return new ComposerPackageConstraint('twig/twig', '>=3.21');
}

It had also drifted. Seven packages were gated above the version their rules need — symfony/framework-bundle at >=3.3 where a rule needs 2.5, symfony/routing at >=6.0 where a rule needs 3.4, and so on — and four packages with rules in the set (var-dumper, intl, uid, filesystem) had no entry at all. Every drift like that silently disables rules.

With nothing left to trigger, SymfonySetProvider goes as well. This changes nothing for users: withComposerBased(symfony: true) already adds SymfonySetList::COMPOSER_BASED directly rather than going through SetGroup::SYMFONY, exactly as it does for PHPUnit. The remaining Symfony sets — Configs, Code Quality, Constructor Injection, SwiftMailer and the attribute sets — stay reachable through their SymfonySetList constants.

rectorphp/rector-src#8292 drops the matching new SymfonySetProvider() from SetProviderCollector.

TwigSetProvider keeps its single twig/twig >=1.12 trigger, since SetGroup::TWIG is wired into withComposerBased().

Kept on purpose

• The per-version set files are untouched and still reachable via SymfonySetList::SYMFONY_* / TwigSetList::TWIG_*.
• Symfony3SetProvider–Symfony8SetProvider stay as classes with an empty provide() until [Sets] Drop Symfony per-version set providers from the collector rector-src#8292 lands, since SetProviderCollector still instantiates them by name. They can be deleted right after.

Left to migrate

Still outside the composer-based encoding, all plain opt-in sets with no version binding:

• Configs, Code Quality, Constructor Injection
• SwiftMailer to Symfony Mailer
• attribute sets: FOS Rest, JMS, Sensiolabs, Symfony, Symfony Validator

And the 209 per-version set files under config/sets/symfony/symfony3..8/ and config/sets/twig/, now reachable only through the set list constants.