fix(bundle): alias the nested token services with their own class

[Spomky]

Fixes #660.

NestedTokenBuilder and NestedTokenLoader (the DI sources) registered their autowiring alias against self::class — the class of the configuration source — instead of the class of the service they create. The resulting aliases were:

Jose\Bundle\JoseFramework\DependencyInjection\Source\NestedToken\NestedTokenLoader $nestedTokenLoader1NestedTokenLoader

Nothing could ever resolve them, so autowiring a nested token loader or builder failed. They now read:

Jose\Component\NestedToken\NestedTokenLoader $nestedTokenLoader1NestedTokenLoader
Jose\Component\NestedToken\NestedTokenBuilder $nestedTokenBuilder1NestedTokenBuilder

The naming convention (<config name> + service kind) is unchanged, and it matches every other source ($jwsLoader1JwsLoader, $builder1JweBuilder, …).

Are the others affected?

No. I went through all 14 registerAliasForArgument() call sites: the twelve others pass the class of the service, and AbstractSource passes $definition->getClass(). Only the two nested token ones were wrong.

To keep it that way, AutowiringAliasesTest loads the bundle extension with the functional test configuration, walks every autowiring alias it registers, and asserts the aliased service is an instance of the aliased type. That covers 22 aliases across all sources today and picks up any new one automatically. It fails on both nested token aliases without the fix.

NestedTokenServiceConsumer in the test bundle reproduces the report end to end: it takes both services through autowiring only, and the two new functional tests check it receives the services from the configuration.

Not addressed here

The $target argument of registerAliasForArgument(), suggested in the issue's additional context, would let people write #[Target('nested_token_loader_1')] instead of the suffixed name. It landed in Symfony 7.4 and this branch supports symfony/dependency-injection: ^7.0|^8.0, so it can't be used unconditionally here. Worth a separate issue on a branch that can raise the requirement — it applies to every source, not just these two.

Test run

Full suite: 777 tests, 38 failures — the same 38 that fail on an untouched 4.1.x checkout. They are all *ConfigurationTest cases where matthiasnoback/symfony-config-test no longer matches the Symfony 8.1 config error messages, unrelated to this change. ECS and PHPStan cannot run on 4.1.x at all (broken tool configuration, already repaired on 4.2.x by #669).