Scrap plugin.yml commands

[dktapps]

Description

It's 2024 and most people just declare them in code anyway.

More seriously, command handlers are like event handlers, and the system we create them by should reflect that. It doesn't make much sense to separate the base info from the implementation the way we do right now, and no one likes being bound to onCommand (see #5960).

In addition, it's currently impractical to do stuff like using localized descriptions, and plugin.yml commands also aren't suited to a future where the command parser actually processes arguments into proper types instead of just passing string[] $args to everything.

The only real downside to scrapping these commands is that it won't be possible to tell what commands a plugin has without running the server and doing /help. However, since many people already don't use plugin.yml for commands, this is kinda a moot point.

We can reduce the friction of creating commands procedurally by implementing changes like #6063.

In the future, we could also implement a system using @doccomments and a magic interface like Listener for registering command handlers if there's a demand for it.

Justification

The whole thing is misconceived. I wrote about this at length in #5960.

This has been discussed for years and years, and I'm frankly amazed that a formal change proposal has never been submitted before.