Rework plugin config system

[DerEchtePilz]

Just an idea I had, can be merged if good and wanted, but can also be closed.
The advantage of this system is that updating the config is possible. New values can be added and user configs that already exist get the new values. Furthermore, this system would also allow removing values if they are no longer needed, if that ever happens.

[DerEchtePilz]

Hmm, the general system works perfectly, however there are issues when dealing with the lists for the config options that are used to convert commands.

Converting this PR to a draft until fixed.

[willkroboth]

I wonder if there is a general library (maybe not even Minecraft specific) for updating and loading commented YAML configurations. That could help create a more generic system that would also work for CommandAPIVelocity, and it would be probably already be well tested and reliable.

[DerEchtePilz]

Maybe Configurate could work, though I haven't used it before, only heard of it.
https://github.com/SpongePowered/Configurate

[willkroboth]

I think it would be good to implement this system for Velocity as well before merging. With #517, the default Bukkit config will eventually need to be split Spigot/Paper for the hook-paper-reload option. Having a system now that can deal with the shared options between Bukkit/Velocity would be nice for implementing the Spigot/Paper split later.

Additionally, it would be nice to see some automated tests for the config updating logic. With the YamlConfiguration#loadFromString and YamlConfiguration#saveToString methods, I imagine these tests could look something like:

String currentString;
YamlConfiguration currentConfig = YamlConfiguration.loadFromString(currentString);

YamlConfiguration updatedConfig = ConfigGenerator.generateWithNewValues(currentConfig);
String updatedString = updatedConfig.saveToString();

assertEquals(expectedString, updatedString);

Tests could include making sure new config options are added, extra config options are removed, options set by the user are carried over, comments are updated separately from values, etc.

Putting both these ideas together, writing tests could be easier if ConfigGenerator was able to do more than just generate the default Bukkit config. Each test could pass in its own custom small set of config options, which would mean expectedString wouldn't need to hold the whole Bukkit config.yml every time.

[Strokkur424]

I haven't really looked too deep into how the code works, but it looks good. I just highlighted some inconsistency

[willkroboth]

Another miscellaneous thing I noticed while testing that didn't fit anywhere else. If I have a config that looks like this:

Once running the server the config gets updated to this:

This doesn't seem like a big deal since - Essentials: null seems to be interpreted the same, but I thought I'd bring it up.

Automated tests might've caught some of the things I brought up, and perhaps more that I missed.