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

Required for lambdas

.. Unless they have 'nope' in their name

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

Was an instance field all along, but always set to null

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

Fixed functions not working properly

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?

Before it they would simply return false, even if a type would match the bounds

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

Is there any reason why not to?

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

I don't think this is the correct call here.
Just that a constructor has no argument does not mean it is a propagated default constructor.