Do not attempt to enable ProtocoLib on untested versions

[lukalt]

Lots of users report issues in which they use an outdated version of ProtocolLib together with a recent version of Minecraft.
In this case, ProtocolLib only prints a single-line warning and proceeds as usual. However, this usually causes during the enabling of the plugin or runtime.

This PR changes this to disable ProtocolLib when the version of Minecraft is not supported.
Users a directed to the GitHub releases page and Jenkins in this case.
If the version is explicitly whitelisted in the config.yml, a warning is printed to the log and ProtocolLib enables as usual.

What do you think about this? @dmulloy2

[dmulloy2]

I suppose it's ultimately a distinction between the reality of the situation and what we had hoped in years past. The idea is that for the most part PL should continue to work in newer versions, at least to some extent. There are various "forward compatibility" measures that work depending on how much Mojang changed. In any event, I think we should only fully disable if there is a major version change (1.20-1.21) as opposed to a minor change (1.20.1-1.20.2)

[lukalt]

Mojang follows the trend to move more and more fields of packets into separate classes. So, the chances are very high that something breaks with an update of Minecraft. And people seem to ignore any warnings in the log (there have been at least 50 issues reporting the same stack trace printed later in the log during the last couple of weeks). Admittedly, PL is currently not really structured in a way that we can expect forward compatibility with upcoming MC versions.

So I would prefer to disable the plugin by default. If the users know what they are doing, they can still configure it to bypass the version check and just print a warning. And users who do not know what they are doing at least know why ProtocolLib is not working properly.