[10.x] Fix parsed input arguments for command events

[bert-w]

This PR fixes the input arguments for CommandStarting and CommandFinished events, which were previously empty because the InputDefinition (Symfony) was bound later than the events.

The following will now work:

Event::listen(function (CommandStarting $event) {
    Log::info('starting ' . $event->command);
    Log::info($event->input->getOptions()); // Previously `[]`, now filled.
    Log::info($event->input->getArguments()); // Previously `[]`, now filled.
});

This is an improvement for #44662 which was later reverted (#44888) because it did not function well when an Artisan command was run through the command line.

This case has now been covered (based on \tests\Integration\Console\CommandSchedulingTest.php which uses an actual artisan file to simulate such call) and also the in-process artisan calls using array (Artisan::call('cmd', ['arg'=> 'abc', '--def' => 123])) and string (Artisan::call('cmd abc --def=123')) syntax have been covered.

[taylorotwell]

I'm not pursuing this again on a patch release.

[bert-w]

ok any chance for master branch?

[taylorotwell]

@bert-w I'll reopen it here for discussion, but this just seems like a big change? Overwriting a whole new method, etc.

[bert-w]

I'll ping @driesvints here since he has previously taken a look at this as well.

The current (old) override of Illuminate\Console\Application::run() is there solely for the purpose of firing 2 events (CommandStarting+CommandFinished). The change to overriding doRunCommand() instead is because at that point in time the default arguments (--help, --quiet etc) have been bound to the Input by Symfony already. Just to be clear, binding is the process of assigning the Input Definition (defined rules for arguments/options from the command) to the current Input which makes sure that everything is according to the spec.

Symfony itself also merges the command input definition $command->mergeApplicationDefinition(); inside the doRunCommand():
https://github.com/symfony/symfony/blob/dc016816f58d913969e60e1c0960ba1af145df4f/src/Symfony/Component/Console/Application.php#L1068

However this happens after the Laravel event has been fired. It works for the Symfony ConsoleCommandEvent event since that dispatches just after this assignment. This PR calls the $command->mergeApplicationDefinition() earlier so the Laravel event has this data available (however this meansmergeApplicationDefinition() is called twice since it happens again by Symfony; I don't see an issue with this though).

I got one idea though which might not be half-bad now I think about it since it prevents this double call: assign the dispatcher property (the Symfony event dispatcher; not compatible with Laravel) and listen to that only in Illuminate\Console\Application, routing and transforming the events to the Laravel dispatcher. I'll create a draft PR.

[bert-w]

This gives another solution to the problem which I think I like more: #46442