Allow registering additional packages in the transformable layer for generated classes about modlauncher

[cpw]

Yes, this might be a way to address the additional classes issue as well.

[marchermans]

We might need to create a proper API which queries the transformers when the modules are created, and asks if they wish to add packages to each module.
Then we could track those and if we notice that we are in such a package during class loading immediately redirect to the Transformer in question?

[Su5eD]

We could add a new Map<String, Set<String>> additionalPackages() method to ITransformationService that would return a map of module names to package names. Before the transformable layer is built, modlauncher would query each transformation service for additional packages, and merge the maps. The resulting package names would then be routed into JarMetadata#descriptor by JarModuleFinder.

Then we could track those and if we notice that we are in such a package during class loading immediately redirect to the Transformer in question?

A possible way could be overriding getClassBytes in TransformingClassLoader and returning an empty array if the package is provided by a transformation service. However, we'd have to expose packageLookup for getting module names, as well as ensuring additional packages don't contain existing package names.
Not sure whether it's worth the effort as it wouldn't really improve performance.