Changes how Classes from Stdlibs are found in the NativeModule so that their Java type parameters properly match the ones from the Stdlibs files

Mwahaha, Jared you will have to review this :manic_laugther:

Provide them as class parameters

It's unavoidable at times

Background: Otherwise they will throw Exceptions because the class definitions are there but not the type infos

Background: We only checked public nondefault, that matched for public statics as well.
Now checks for public nodefault abstract

Also TODO: Functional Type may not be part of functional Method's signature

Background: If the return type was a generic parameter, that early it wouldn't have been populated yet, and why load the return type as first thing in a method anyways?

Background: Javac creates an ACC_BRIDGE method to deal with the signature change (either a covariant parameter or contravariant return type change).
Hence there are two declared methods, one that is the old one, one that is new. For Signatures where only the return type changed this caused both to be registered and an ambiguity later where ZC could not determine which to choose

Now it doesn't select the first nondefault method but the first public nondefault method

Reason behind this is to prevent NoClassDefFoundErrors for working with Sided classes in MCF

Let's see if putting them all into one TypeVariableContext works..?

Also, a lambda that returns void cannot conclude the generic header. How should we deal with this?

This reverts commit 95d9aa2b32.

Reason was that it tried to invokeInterface whereas a bridge redirects to a local (virtual) method.
The local method was flagged incorrectly as the same type as the bridger which would be interface, hence the error

They worked in my simple, void test example

The Optional annotation is parameter, not type bound

E.g. IIngredient has a method that accepts an IItemStack, which is a sub-interface