Expansions classes now properly get a number suffix so that expansion classes and scripts no longer share the same name. Also fixes that scripts and expansions cant be in one file

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

Required for Type assertion, else a 'Object is not assignable to X' will follow

This time for nonexpansions.
The method signatures should be calculated correctly now, though they are still only filled with nulls

Fixed functions not working properly

They used the signature instead of the description, so there was an AIOOB when the compiler tried to cast a 'TT;' as that only exists in signatures, not in descriptions

This commit at least fixes that some classes have the same name, e.g. the name of an expansion class and the name of the script block part within the file.

WIP since it still needs more doing and a way to properly store already generated names.

Who would've thought that a 'this' can be a non-object :thinking-face:

Reason: Some iterators use the generated USizeRange which would throw a ClassCastException

Signature: Include the type in the signature if it is an expansion method
Call: Call invokeStatic if its an expansion method

- Apparently, ZC tried to create (empty) java.lang and java.util classes
- Script blocks and Module Highleveldefinitions create the same class and they aren't merged but the scripts blocks (which run later) try to replace the definitions. Workaround by preventing 2nd registrations and printing to System.err

Fixes an issue where Std::List would implement Iterable and therefore break the scripts.

Now instead uses Objects.toString(...) for them

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

Functional interface wrappers should work now
Implementing a method with a signature differing from the actual one (e.g. when dealing with generics) now creates a proper bridge method
The Java Bytecde compiler used an incorrect method in checkCast
We now no longer use hardcoded 'accept's as method names but whatever the context tells us to.