Add artisan dev command

[joetannenbaum]

Adds a new php artisan dev command that runs your development processes (server, queue worker, log tailing, Vite) concurrently using concurrently. The default behavior is effectively the same as the current composer dev.

Commands are registered via DevCommands and can be customized, filtered with only/except, and color-coded.

Includes automatic Node package manager detection (npm, yarn, pnpm, bun) and prevents vendor packages from registering dev commands.

The Pain Point

Adding commands to composer dev is tedious and error-prone. With this new convention, you can simply add the following to your service provider, and the new commands will be included in the mix:

DevCommands::artisan('reverb:start');
DevCommands::register('stripe listen --forward-to ' . config('app.url'));

You can optionally provide a name for the process as the second argument; otherwise, the name will be the first segment before the first space.

If you'd like a specific color for the command:

DevCommands::artisan('reverb:start', 'reverb')->orange();
DevCommands::register('stripe listen --forward-to ' . config('app.url'))->green();

Vendor Protection

DevCommands explicitly prohibits automatic command registration from the vendor directory. That said, it does allow a package to provide a helper that can be called from userland code to register commands, for example:

Reverb::registerDevCommands();

I'd like more eyes on this part of the code, as it's the most sensitive area of the changes.

Bonus: Node Package Manager Helper

This PR also includes NodePackageManager, which is probably overdue at this point. It auto-detects the package manager based on the lockfiles present, which allows a generic DevCommand like the following to auto-resolve to the correct command for the project:

DevCommand::node('dev'); // pnpm run dev
DevCommand::nodeExec('prettier') // pnpm dlx prettier

For the scope of this PR, I kept the helper limited to the methods that were necessary for these changes, but they can be easily expanded in the future.

[joetannenbaum]

Also, a subtle gotcha we should consider: commands are keyed by name, and if you don't provide a name it will be derived as described in the PR description. I think the chance of collision is low, making name required would avoid this altogether. Just wanted to collect the least amount of information up front.