Create `automated-tests-shaded` example project to test using the test toolkit

Resolves #356

Alternative idea to current work on `dev/public-test-suite`

Attempts to allow developers to test their commands independently of any version or nms stuff. Currently, most of the methods throw an UnimplementedMethodException, but I have implemented enough to get the simple `PingPongCommandTests` file to work as a proof of concept.

TODO:
- Implement the methods required to test:
  - `commandapi-bukkit-plugin` based projects
  - Common arguments
  - Suggestions
- Write documentation
- Maybe add a module to more rigorously test the toolkit without cluttering the example project

I think if we can get a simple version working and published as a snapshot, users can try it out and identify methods that need to be implemented.

Add automated-tests example project for showing testing with `commandapi-bukkit-plugin`

Remove unnecessary plugin constructors (it seems MockBukkit does not need them)

Add MockCommandAPIPluginLoadingTests to thoroughly test loading options without cluttering example projects

Fix some typos

Fix some logging-based warnings

…ndAPITestUtilities

Add DispatchCommandUtilitiesTests to fully test these methods

Add CommandTestBase to provide utilities when testing the test toolkit

Enable Jacoco code coverage report for `commandapi-test-toolkit`

Add some comments

Add CommandAPIHandlerSpy and ExecutionQueue to intercept and track command executions

Add AssertArgumentUtilitiesTests and ExecutionQueueTests

Add IntegerRangeArgumentType to let Brigadier parse input to IntegerRange. Currently, the exceptions thrown are just their raw strings. I couldn't seem to get the translations keys `argument.range.empty` and `argument.range.swapped` to resolve due to MockBukkit/MockBukkit#1040.

Implement Parser builder to make defining object parsers easier. Inspired by Brigadier command parse trees and #544.

Add IntegerRangeArgumentTests

e08a90a made `CommandAPIHandler#generateCommand` public instead of protected so CommandAPIHandlerSpy could intercept invocations. This promoted a javadoc warning into a javadoc error that stopped the build.

Javadocs incorrectly indicated that `CommandAPIHandler#generateCommand` could throw a CommandSyntaxException, when it actually returns a lambda that could throw that exception (Brigadier's Command interface).

Add AssertSuggestionUtilitiesTest

Some tweaks to internal testing error messages

Allows verifying the input to command executors when they end up throwing a WrapperCommandSyntaxException

…ilities

If the tests don't check the case where an assertion failed, the supplier won't run, so Jacoco can detect uncovered code.

Cover and fix such a gap in `CommandAPITestUtilities#getExecutionInfo`

… to test toolkit

I was initially going to just do PlayerArgument because I thought it would have simple suggestions. I then realized that OfflinePlayerArgument was basically the same argument, so I did that as well.

The ProfileArgumentType is also basically half a EntitySelectorParser, so I did the EntitySelectorArgument as well, though selector options are currently left unimplemented.

I wrote tests for all these, and that took a while.

I still haven't implemented any ArgumentType suggestions code...

I think the way I set up the Parser builder to support suggestions makes sense. It works at least.

Parser now returns Result object, which tracks whether an object was returned or an exception was thrown, as well as a SuggestionProvider for the current location. Default methods added to Parser to handle this result appropriately when either parsing or suggesting.

Moved Parser into its own package and extracted some of the inner classes and interfaces. Package-protected access accomplishes the same sort of encapsulation.

Added methods to CommandAPITestUtilities to assert that suggestions are located at a specific offset index.

Added tests~

…ir tests

This makes it possible to avoid UnimplementedMethodExceptions by overriding and implementing the method yourself

NOTE: CommandAPIVersionHandler was changed from an interface to an abstract class so the test-toolkit version could have a non-final field. I don't think this affects anything else.

Updated test toolkit's MockBukkit version to include MockBukkit/MockBukkit#1077, which allows accessing Minecraft Language codes.

Moved utilities for creating mock argument parsers into ArgumentUtilities class.

Made example project build script run maven tests, so the tests in the `automated-tests` and `automated-tests-shaded` example projects are run by GitHub Actions.

It seems that MockBukkit and Paper API need to match exactly. This seems a little annoying, because if something in Paper updates their API, a MockBukkit version can suddenly stop working, but you'll only realize once your local cached copy of paper-api updates.

Users may want to use these methods if they are trying to implement an ArgumentType that isn't currently provided by the test toolkit. This ideally also makes the Parser system understandable for developers who are not me :P.

Missed this when 1.21 came out and added @n.
Future idea: allow users to specify a version to account for behavior like this that changes by version. For now though, matching latest behavior makes sense.

Other one line if statements do have `{ }`, so these were inconsistent.