API additions + changes for Configurate 4

[zml2008]

SpongeAPI | SpongeCommon

This updates the API for changes in Configurate, and to move away from the Guava TypeToken.

API spec changes

The biggest non-obvious changes are to injection -- since these are defined in the implementation they aren't captured super well. I've added in a few new injectable types:

• ConfigurationReference<CommentedConfigurationNode>: both shared and private roots, provides an auto-reloading configuration
• TypeSerializerCollection: Exposes the Sponge-defined serializers

and set up some customized default options for configurations:

• implicit initialization is enabled for object-mapped values
• defaults are automatically copied

[zml2008]

Alright, I've made some more progress on this PR, and most of the groundwork is in.

The big change (apart from Configurate 4 itself) is moving away from Guava's TypeToken. While performing that migration, I've also been moving the API to align with the pattern I've begun using in Configurate, which avoids a lot of unnecessary TypeToken usage.

For areas where a type is expected from a user, two variants are provided: One that accepts a TypeToken<T> and one that accepts a Class<T>. For areas where a type is provided to a user, a plain Type is provided. In most cases, the actual value of the T parameter in a TypeToken is not actually known at runtime, and so it provides a false sense of type-safety. This leaves the TypeToken as a tool for type capture more type storage. For simple cases, this means that users don't have to provide a TypeToken when one is not necessary to fully express their type. For example, most of the test plugins in common barely need TypeToken. Some areas affected quite a bit by this change are the key-type objects in API - Key, Parameter.Key, and EventContextKey, and the API that works with them.

Where this strategy gets a bit tricky is for methods that return TypeToken in interfaces designed to be implemented by users. I think most of those will have to stay, since we can't have two options for return types on the method, and in those cases the type parameter is needed to prevent errors -- for example in CommandRegistrar

An area that will need a bit more thought is the catalog registry. While a lot of its API takes TypeToken, internally it still uses Class, which results in a bit of a nasty implementation. I don't know if it makes sense to move the internal storage over to Type and make the system generic-aware, or to make sure all the access and registration methods are paired.

With these changes I hope to constrain the spread of TypeTokens to only types that need to capture generic parameters, which will help reduce the verbosity of the API. The majority of the constants in TypeTokens should become irrelevant.

[dualspiral]

Looks fine from the commands end (does on Common too, too lazy to post twice).

[dualspiral]

The javadoc got broken here!