Cache Bukkit Command when wrapping CommandNodes

[willkroboth]

Reopens #11385.

Resolves #11378 by "restoring" the Spigot behavior where VanillaCommandNodes are only created once. Before this commit, BukkitBrigForwardingMap would create a new VanillaCommandWrapper each time a CommandNode was requested via the Bukkit CommandMap. This meant that calls to Command#setPermission would not persist between retrievals from the map.

This allows command frameworks that insert CommandNodes directly into the Brigadier dispatcher to change the permission String of the VanillaCommandNodes created for their commands, rather than it always being the default "minecraft.commands.<name>".

As discussed on the original PR, it's probably a good idea to eventually migrate the behavior of Bukkit#dispatchCommand to use Brigadier directly rather than working via the Bukkit CommandMap, which causes issues like this. Now that the hardfork is real, Paper may eventually fully remove CommandMap in favor of direct Brigadier API, which would make fixing CommandMap behavior like this PR does irrelevant. However, I feel like while Paper is still using the CommandMap fixes like this are still valuable.

If we'd rather fix #11378 by changing the implementation of Bukkit#dispatchCommand to use Brigadier directly, feel free to close this PR. Although, while not a requirement of the Map interface, it is also neat when map.get(a) == map.get(a) for all a, which isn't necessarily true for the BukkitBrigForwardingMap before this PR.

[Owen1212055]

This allows command frameworks that insert CommandNodes directly into the Brigadier dispatcher to change the permission String of the VanillaCommandNodes created for their commands, rather than it always being the default "minecraft.commands.".

The issue that if at any point Bukkit#dispatchCommand is reimplemented, wouldnt the above change kinda be invalidated? I find it very likely that bukkit dispatcher will be ripped out at one point or another, so I don't think this will have any effect command execution wise?

[willkroboth]

Indeed, if CommandMap is ever removed, then BukkitBrigForwardingMap would not need to exist, and nothing would use the new CommandNode.wrappedBukkitCommandCached field added by this PR.

This PR only fixes CommandMap behavior, which is currently used by Bukkit#dispatchCommand. The current API is a bit broken in this edge case, and this PR fixes that bug. I don't expect CommandMap is going to be removed immediately, so I think it is a good idea to merge this PR. Since the change is so small, it will be obvious how to undo the changes from here when the time comes, so I don't think there is any downside to merging this PR.

But yeah, again, if we just want to fix #11378 by changing the implementation of Bukkit#dispatchCommand and don't care about the map identity thing, feel free to close this PR.

[Owen1212055]

I believe that it's the best solution to instead refactor bukkit dispatch command to use the brigadier system rather than going through the command map.

Thank you for your contribution, however. Hopefully I will be able to work on this refactor rather soon as to not hopefully keep this behavior for too much longer.