Replace `AsynchronousCommandExecutionCoordinator.newBuilder().build()` with `CommandExecutionCoordinator.simpleCoordinator()`. (`AsynchronousCommandExecutionCoordinator.newBuilder().build()` does not work as it's missing a generic type argument, needs to be `AsynchronousCommandExecutionCoordinator.<CommandSender>newBuilder().build()`)
* Fix NPE with webhook messages.
Webhook messages would be constructed as `JDAGuildSender`, which calls `Objects.requireNonNull(event.getMember())` however the JDA documentation states that the `getMember()` method will `be null in case of Message being received in a PrivateChannel or isWebhookMessage() returning true.` If the message is a webhook message, a generic `JDACommandSender` instance will be constructed instead of a `JDAGuildSender`
* Add webhook fix to changelog
* cloud-minecraft: Support preserving component error messages
Any exception thrown by an argument parser that is a
ComponentMessageThrowable will now have its component message directly
queried.
* minecraft-extras: Add Component-based description handling for help
* Apply review comments
- Ensure that the parsing modes list cannot be empty when constructing `MessageParser`
- Don't proceed if the command context does not have the message event stored
- Don't proceed if the message was not sent in a guild
- Remove `|| modes.size() == 1` check in channel mention parsing
If only `ParserMode.MENTION` was set as a parsing mode, the initial check for `input.endsWith(">")` would be bypassed and the input would begin to be parsed like a mention. If the input was less than three characters long then the `substring` calls would give a very ambiguous error along the lines of `begin 2, end X-1, length X`.
This commit fixes this issue by adding a check to make sure the input is an actual user mention. If the input isn't a mention then an exception will be set stating that the sender's input was not a user mention.
In addition, this commit also removes the `modes.size() == 1` check in the mention parser. I'm not sure why this was there to begin with, but I don't think that the input parsing check should be bypassed because only one parsing mode is specified. I settled on a check in the `UserParser` constructor to make sure that the parsing modes list isn't empty in order to ensure that at least one parser mode handles the input.
