[VersionBonding] Allow a rule to require multiple composer package constraints at once

[TomasVotruba]

Enables a version-bonded rule to declare more than one composer package constraint, all of which must be satisfied for the rule to run.

Why

Some rules only make sense when two packages are new enough at the same time. Example from rectorphp/rector#9856: the #[AsTwigFilter] / #[AsTwigFunction] / #[AsTwigTest] attributes exist in twig/twig 3.21, but Symfony only autoregisters extension-less classes built from them in symfony/twig-bridge 7.3. A rule gated on twig alone fires on Symfony 6.4, strips TwigExtension, and silently loses every filter/function.

Until now provideComposerPackageConstraint() could return a single constraint only.

What

ComposerPackageConstraintInterface::provideComposerPackageConstraint() may now return either a single ComposerPackageConstraint (unchanged) or a list<ComposerPackageConstraint>. The return type widened to ComposerPackageConstraint|array, so every existing implementer stays valid by covariance — no rule needs to change.

The filter requires all constraints to be satisfied; a single miss (or missing package) skips the rule:

public function provideComposerPackageConstraint(): array
{
    return [
        new ComposerPackageConstraint('twig/twig', '>=3.21'),
        new ComposerPackageConstraint('symfony/twig-bridge', '>=7.3'),
    ];
}

bin/rector composer-based (the debug table) now prints one row per constraint.

The matching rule fix lives in a follow-up rector-symfony PR that depends on this one.

[TomasVotruba]

Merging as CI fail unrelated: on composer install