Fix hierarchy computation of boot layer classes

[Su5eD]

The issue

As reported in #27, ModuleClassLoader fails to read bytes of libraries on the java boot module layer used in transformers. This happens because it's trying to find resources on the PlatformClassLoader instead of the AppClassLoader.
See here for a full explanation of the issue by @sciwhiz12.

The solution

Quote from sciwhiz's explanation:

Therefore, the solution is that the above error be corrected by changing the use of ClassLoader.getPlatformClassLoader() to ClassLoader.getSystemClassLoader() instead, so the resolution of class bytes for ASM, SJH, and BSL (or any other class whose module is in the ignore list configured in BSL and exists on the application class loader) works as expected.

[marchermans]

@Su5eD How have you tested that this won't be causing any issues down the line with classpath collisions?

[Su5eD]

The system classloader primarily looks for class resources (e.g. those containing a fully qualified class name, such as cpw/mods/niofs/union/UnionFileSystem.class) in the class' module, so the read resource is always identical to the loaded class. In case a class from an unnamed module is used in a transformer, reading it will be successful, although the game will crash if it ever tries to load the class. This, however, shouldn't happen with our current setup.

Alternatively, we can keep the platform classloader and throw a ClassNotFoundException if the resource can not be found, notifying modlauncher to load the class and use computeHierarchyFromClass instead.

[marchermans]

I know how it works, my problem is that the call to ClassLoader.getSystemClassLoader() gives access to a classloader which is not in module mode.
And that is something we should prevent.

[marchermans]

This was talked through on discord:
The proposed change here violates several constraints set by the original design.
However, a proper solution is already in place it is just not properly working.

The current implementation expects the transforming classloader to throw an exception if it could not load the transformed class bytecode, this is not happening, it is just returning an empty array, causing the crash.

Proposal for changes:

1. Prevent transforms from running on an empty byte array (this is also happening)
2. Make the transform classloader throw an exception when an empty byte array was loaded from the disk.

This should then enable the intended code path with compatible loading to function again.

[marchermans]

This is indeed a good idea, since this would else pipe system classes potentially through transformers.
And the call site takes care of this dynamically.

[marchermans]

This looks much better now, once I figure out how to properly test this stuff, I will pull it out of draft and start the triaging and testing procedure....

[marchermans]

Testing procedures have been setup.
Last call for this PR before I merge it in a couple of days.