[1.16.3] Adds overloads of the compat methods to allow for two mod id's

[EltrutLikes]

This PR adds overloads of the compat methods to allow for compatibility between two different mods. This is used, for example, in Enhanced Mushrooms for glowshroom beehives or in Cookielicious for sweet berry cookie tile vertical slabs. A common use of these methods is for allowing compatibility between some mod and Quark's vertical slabs and is used often enough that I think it warrants a PR here.

[EltrutLikes]

I've fixed the documentation issues and changed the methods to take in an ArrayList of mod id's and a boolean isIndev instead of two mod id's. I also added a compat method for the chests as well just for completeness and I switched the parameters of the original chest compat method to match the other compat methods. Let me know if you would like me to revert that though. :)

[jacksonhardaway]

Would probably be best to use a String varargs instead of an ArrayList, since you don't need to keep the order intact plus it'll just be cleaner for developers to put in multiple strings.

Also, instead of using an isIndev boolean, it'd probably be better to just check if the environment is a deobf environment.

[EltrutLikes]

Apologies for the noobiness, I'm still learning Java.

A question though: if I switch it over to varargs, would you like me to combine the multi-mod compat method, one-mod compat method, and normal method into one (since one-mod and normal would correspond to 1 and 0 parameters, respectively) or just leave them as is?

[EltrutLikes]

I switched over to a String varargs for the mod id list, removed isIndev as a parameter in favor of just checking whether it is a dev environment or not, moved the imports back to where they were, and combined the multi-mod and single mod compat methods.

I feel that it is now redundant to have for example both a createBlock and createCompatBlock method with the String varargs since createBlock just corresponds to the createCompatBlock with no parameters, but I understand if for clarity you would like to keep both.

[bageldotjpg]

Ok, sorry for changing up things yet again but Jackson, Smelly and I were discussing in VC yesterday and determined some things.

• It shouldn't automatically make it show up if it is a dev environment, because sometimes that could be an issue; eg: you messed up your compat method so it shows up when the wrong mod is present or it shows up when your own mod is present. They should only show up if you changed something specific so you know you are doing something right.

• To do this, you can just change the modid arg to whatever mod you are working on's modid to test. Because in reality they don't need to be tested that often. e.g: testing a Quark compat object for Atmospheric? Change the compat id to Atmospheric.

We also determined the change to var args, while easy to use, is rather unclean in a development format, and forcing it upon all methods is not a great idea, because that creates a massive breaking change that is also not very readable. So the vararg methods should be new methods and leave the old ones alone, since they are rarely used (they've never been used by us) and not worth creating a big breaking change over.

[EltrutLikes]

I restored the original compat methods and removed the if (FMLEnvironment.production) conditional from the multiple compat methods (which are now once again overloads of the original methods). Hopefully third time is a charm :)

[SmellyModder]

I updated the 1.16.3 branch to 1.16.4 so this got closed. Open a new PR for this on the 1.16.4 branch.