This completes and fully enables a new feature called "Conditions"
We already had some forms of conditions built into @Flags such as
on the Player for itemheld.
However, letting end users add additional restrictions to existing context
handlers such as players is not possible without redefining the context.
That's not friendly nor scalable.
Flags will now be primarily only for controlling how to resolve a context,
and then Conditions will then be the way to validate the context and trigger
a failure if the condition is not met.
Conditions can be placed on Command Class, Methods, or individual Parameters.
This adds the ability for plugins to define completion handlers as async safe (not on games main thread)
When they are defined async safe, and ran on a Paper 1.12.2+ server, with a Paper ACF manager,
completions will be handled mostly async, letting you safely do heavier operations in tab completions.
Slight risk of API breakage but risk is minimal enough that I'm not bumping versions.
0.5.0 Migration guide suggested (Platform)CommandManager, which will set the generics for you.
Only if you stored the ref as the Abstract CommandManager would you now run into generic issues.
Also, cleaned up the sendMessage API's to not need Object now since we know the Generic type.
This is technically an API break, but considering Locales was only released last night and
the likelyhood someone overrode that method, is unlikey.
If you did, just fix the method signature! Sorry <3
For consistency, make Completion Handlers be implemented the same way Context Handlers are.
Previously when we added the Context parameter, we left the original signature in place and simply tacked , c on the end.
This made migration easier than changing all completion handlers bodies.
But since 0.5.0 is a big migration already, let's just get it over with.
See changes to Bukkit default completions and the example plugin for migration example.
Aikar