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.

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

fixes issue about unknown type parameters for StdLibs::List

This reverts commit 95d9aa2b32.

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

Essentially they are functions that accept the parsedExpression and the compilescope.
They return either null or a PartialExpression.
If they dont return null then the used partialexpression will be used instead of whatever the parsedexpression wouldve compiled to

Now pritns the array element type and the faulty element's type
Also changed this for assoc Arrays

Only WIP, tries to check the same type without storage tags and see if it can cast then.