This PR started out as an effort to decouple Command and CommandMap, but it's turned into a bit more than that.
A summary of changes:
## UX
- Added `cmdalias create`, `cmdalias delete` and `cmdalias list` commands
- `/help` now shows prefixed names such as `pocketmine:help`
- Prefixed command name (e.g. `pocketmine:help`) are now visible to Minecraft clients
- Permission denied messages are now able to show more useful context when e.g. checking subcommand permissions
- Multiple commands claiming an alias make the alias unusable (an error will be shown when used telling the user to pick from the namespaced names), instead of whichever plugin loaded last getting lucky
## API
- Added `CommandAliasMap`, which handles mapping of aliases to namespaced command IDs
- Added `CommandSender->getCommandAliasMap()` for user-specific aliases
- Added `CommandMap->getAliasMap()` for global fallback aliases
- `Command` no longer tracks its own registered aliases (now the job of `CommandMap`), breaking circular dependency
- Aliases must now be provided to `CommandMap->register()`
- Aliases can now be individually registered and unregistered without re-registering/unregistering the whole command using `CommandAliasMap` APIs
- Aliases are no longer namespaced, only the main command name (e.g. `pocketmine:?` is now gone while `pocketmine:help` still exists)
- `Command` now requires a `$namespace` parameter, which replaces the old `$fallbackPrefix` parameter of `register()`. It should be set to the name of the plugin.
Relevant issues
- #6508
- #3371 - this PR doesn't implement storage, but allows configuration of per-user aliases during server runtime
it doesn't make sense to have to parse the string every time we want to verify permissions, nor to expect that people will somehow know to use ; to separate them without it being documented anywhere...
this resolves many security issues, as well as removing a ton of boilerplate code.
It may be desirable to react to permission denied; this can be done by overriding Command->testPermission(), or by using setPermissionMessage() to set a custom permission denied message.
this makes translation usage much more statically analysable.
The only places this isn't used are:
- places that prefix translations with colours (those are still a problem)
- places where server/client translations don't match (e.g. gameMode.changed accepts different parameters in vanilla than in PM)
this is an impressively dumb idea.
the playerdata is not used here in any capacity so it doesn't make sense to load it, especially considering that it takes a significant amount of time.
