[9.x] Lazy load Laravel commands

[paras-malhotra]

As a follow-up to #34873, this PR lazy loads all commands shipped with Laravel.

Breaking Changes
All commands were previously bound with the command.* binding names and are now bound by class name. Why? Because lazy loading implementation requires the container to resolve by class name. The command.* binding keys were unused elsewhere in the framework but if we need to support those keys as well, I can modify the PR to add aliases for those keys.

Memory Reduction
I confirmed that after this PR, the constructors of the Laravel commands are no longer invoked. With memory_get_usage, I confirmed that memory usage is now reduced by ~130KB (by lazy loading the commands shipped with Laravel). I'm not quite sure if GC is playing a role here and the actual reduction is higher. Of course, coupled with package and app commands, the memory reduction would be higher.

[taylorotwell]

What is the total memory usage before and after? 130kb out of what total?

[paras-malhotra]

@taylorotwell, the total memory of the test command shows as 21.2 MB. The documentation on memory_get_usage reads that it triggers GC, so I'm not 100% sure that this is the only gain.

Here's the code for TestCommand@handle:

public function handle()
{
    $memory = round(memory_get_usage() / 1024 / 1024, 2);

    $this->info("Memory used: {$memory} MB");
    
    return 0;
}

[taylorotwell]

So I'm curious if there is a way in ArtisanServiceProvider to feed Artisan a list of the default names directly as a large array so that the class files themselves aren't even included from disk. I think this would give quite a bit more savings.

[GrahamCampbell]

Once they have been loaded once, production opcache settings prevents them being loaded again.

[paras-malhotra]

All we're giving the command loader is a mapping array of ['command:name' => Command::class]. We need to provide the class names so that if the command is indeed called, the loader can resolve/instantiate the command class from the container