This PR was merged into the 3.4 branch.Discussion----------[Console] Add support for command lazy-loading| Q             | A| ------------- | ---| Branch?       | 3.4| Bug fix?      | no| New feature?  | yes| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#12063#16438#13946#21781| License       | MIT| Doc PR        | todoThis PR adds command lazy-loading support to the console, based on PSR-11 and DI tags.(#12063 (comment))Commands registered as services which set the `command` attribute on their `console.command` tag are now instantiated when calling `Application::get()` instead of all instantiated at `run()`.__Usage__```yamlapp.command.heavy:    tags:        - { name: console.command, command: app:heavy }```This way private command services can be inlined (no public aliases, remain really private).With console+PSR11 implem only:```php$application = new Application();$container = new ServiceLocator(['heavy' => function () { return new Heavy(); }]);$application->setCommandLoader(new ContainerCommandLoader($container, ['app:heavy' => 'heavy']);```Implementation is widely inspired from Twig runtime loaders (without the definition/runtime separation which is not needed here).Commits-------7f97519 Add support for command lazy-loading

…application with lazy-loading needs (ogizanagi)This PR was merged into the 3.4 branch.Discussion----------[Console] Add a factory command loader for standalone application with lazy-loading needs| Q             | A| ------------- | ---| Branch?       | 3.4 <!-- see comment below -->| Bug fix?      | no| New feature?  | yes <!-- don't forget updating src/**/CHANGELOG.md files -->| BC breaks?    | no| Deprecations? | no <!-- don't forget updating UPGRADE-*.md files -->| Tests pass?   | yes (failure unrelated)| Fixed tickets |#22734 (comment) <!-- #-prefixed issue number(s), if any -->| License       | MIT| Doc PR        | todo (withsymfony/symfony-docs#8147)So standalone applications can also benefit from the lazy loading feature without requiring a PSR-11 implementation specifically for this need.The loader does not memoize any resolved command from factories, as it's the `Application` responsibility and the `ContainerCommandLoader` does not either (the PSR-11 does not enforce two successive calls to return the same value).Commits-------9b40b4a [Console] Add a factory command loader for standalone application with lazy-loading needs

…application with lazy-loading needs (ogizanagi)This PR was merged into the 3.4 branch.Discussion----------[Console] Add a factory command loader for standalone application with lazy-loading needs| Q             | A| ------------- | ---| Branch?       | 3.4 <!-- see comment below -->| Bug fix?      | no| New feature?  | yes <!-- don't forget updating src/**/CHANGELOG.md files -->| BC breaks?    | no| Deprecations? | no <!-- don't forget updating UPGRADE-*.md files -->| Tests pass?   | yes (failure unrelated)| Fixed tickets |symfony/symfony#22734 (comment) <!-- #-prefixed issue number(s), if any -->| License       | MIT| Doc PR        | todo (withsymfony/symfony-docs#8147)So standalone applications can also benefit from the lazy loading feature without requiring a PSR-11 implementation specifically for this need.The loader does not memoize any resolved command from factories, as it's the `Application` responsibility and the `ContainerCommandLoader` does not either (the PSR-11 does not enforce two successive calls to return the same value).Commits-------9b40b4a [Console] Add a factory command loader for standalone application with lazy-loading needs

…oconfigure enabled (chalasr)This PR was merged into the 3.4 branch.Discussion----------[Console] Fix registering lazy command services with autoconfigure enabled| Q             | A| ------------- | ---| Branch?       | 3.4| Bug fix?      | no| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | n/a| License       | MIT| Doc PR        | n/aFor```yaml_defaults:    autoconfigure: trueApp\:    resource: '../../src/*'App\Command\FooCommand:    tags:        - { name: console.command, command: foo }```Before you get the following error:> Missing "command" attribute on tag "console.command" for service "App\Command\FooCommand"Now the command is lazy.----Btw,@Tobion's#22734 (comment)> Wouldn't it be more straightforward if aliases are just the additional tags using the command attribute as well?Then there is no need for an alias property at all and this strange condition doesn't apply either.Partially addressed here by removing the need for repeating the `command` attribute on each `console.command` tag```yaml# beforetags:    - { name: console.command, command: foo }    - { name: console.command, command: foo, alias: foobar }# aftertags:    - { name: console.command, command: foo }    - { name: console.command, alias: foobar }```Tobias proposal:```yamltags:    - { name: console.command, command: app:my-command }    - { name: console.command, command: app:my-alias }```I wanted to propose exactly the same at first, but finally found more clear to add a specific attribute for aliases, especially because relying on the order on which tags are defined sounds less good to me. Please tell me about your preference.(And sorry for the noise around this feature, I want to polish it for 3.4)Commits-------8a71aa3 Fix registering lazy command services with autoconfigure enabled

…oconfigure enabled (chalasr)This PR was merged into the 3.4 branch.Discussion----------[Console] Fix registering lazy command services with autoconfigure enabled| Q             | A| ------------- | ---| Branch?       | 3.4| Bug fix?      | no| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | n/a| License       | MIT| Doc PR        | n/aFor```yaml_defaults:    autoconfigure: trueApp\:    resource: '../../src/*'App\Command\FooCommand:    tags:        - { name: console.command, command: foo }```Before you get the following error:> Missing "command" attribute on tag "console.command" for service "App\Command\FooCommand"Now the command is lazy.----Btw,@Tobion'ssymfony/symfony#22734 (comment)> Wouldn't it be more straightforward if aliases are just the additional tags using the command attribute as well?Then there is no need for an alias property at all and this strange condition doesn't apply either.Partially addressed here by removing the need for repeating the `command` attribute on each `console.command` tag```yaml# beforetags:    - { name: console.command, command: foo }    - { name: console.command, command: foo, alias: foobar }# aftertags:    - { name: console.command, command: foo }    - { name: console.command, alias: foobar }```Tobias proposal:```yamltags:    - { name: console.command, command: app:my-command }    - { name: console.command, command: app:my-alias }```I wanted to propose exactly the same at first, but finally found more clear to add a specific attribute for aliases, especially because relying on the order on which tags are defined sounds less good to me. Please tell me about your preference.(And sorry for the noise around this feature, I want to polish it for 3.4)Commits-------8a71aa31bb Fix registering lazy command services with autoconfigure enabled