[make:command] Update command generation to support invokables and interactively ask for arguments and options

[Kefisu]

This PR introduces support for generating Invokable Commands and interactively will ask to provide options and arguments for the command just as the make:entity would. Currently it is supporting the Symfony 7.3 specification of functionalities.

If the kernel version is below 7.3 it will hide any invokable functionality. If the Kernel version supports invokable commands it will swap over to the invokable system. A user can use --no-invokable to revert back to the inheritance based command.

I see that the invokable generation is duplicated by PR #1746, I'll keep this PR open to support interactivity in generating the command in it's entirety

Some screenshots of the generation process:

Which would in turn generate a command looking like:

[Kefisu]

The only two faliing CI checks are seemingly not due to any changes made in this PR.

[seizan8]

Wouldn't it be more better to call the templates "InheritanceCommand" and "InvokableCommand" instead of just "Command"? Making it more clear, what the difference is.

[yceruto]

just a related idea: if the list of arguments and options is long (more than two or three?) the maker could apply the #[MapInput] strategy instead. That means defining the command inputs in a separate model class.

Ref: symfony/symfony#61478

[Kefisu]

Wouldn't it be more better to call the templates "InheritanceCommand" and "InvokableCommand" instead of just "Command"? Making it more clear, what the difference is.

@seizan8 That's a very good suggestion, Thank you! I've updated it

[Kefisu]

just a related idea: if the list of arguments and options is long (more than two or three?) the maker could apply the #[MapInput] strategy instead. That means defining the command inputs in a separate model class.

Ref: symfony/symfony#61478

@yceruto that would be a great addition, I'm currently working on bringing the Symfony 7.4 changes into the command.

I wouldn't automatically swap it over to a DTO if the arguments exceed 2 or 3 but keep the choice with the user and prompt them to ask if they wish to place the input in a DTO instead.

Don't know if this is something you would agree on?