More hygenic class loading from plugins

[jedediah]

Change the way classes are resolved from within plugins:

• Always load classes from within the plugin's own jar if present
• Next, search the jars of the plugin's dependencies, in declaration order
• Finally, delegate to the default class loader, which does NOT search any plugins
• Plugins not listed as dependencies are completely invisible

This allows different plugins to use different classes with the same name, effectively allowing multiple versions of shared libraries to coexist peacefully. This fixes a lot of headaches we've been having with shared code.

The caveat is that you absolutely cannot in any way reference more than one version of a shared class. Doing so will cause weird LinkageErrors. So, e.g. if you shade your own version of Guava, you can't reference any method or field from another plugin, or from Bukkit, that was linked against a different Guava, even if it's the same version of Guava.

[twizmwazin]

Generally hasn't the solution to this always been just to relocate shaded libraries internally? Ex relocating com.google.common to my.namespace.project.libs.guava. Your solution is probably better than relocating just because it doesn't rely on plugin devs to know what they are doing, however this could theoretically lead to incompatibility with bukkit plugins not considering this patch.

[jedediah]

Added a bukkit.yml toggle for this named settings.isolate-plugins. When isolation is disabled, which is the default, classes are resolved the same way they were before i.e. Bukkit first, then all plugins in the order they loaded. This should avoid breaking anything.

[jedediah]

I also removed the old class loading patch and put this one on top. The other patches in the diff were just renumbered, no other changes.