Speedup jar package scanning

[Technici4n]

I noted that building the module references was quite slow on the FC pack, so I propose these two simple changes:

• Some mods have a ton of assets and it takes forever to scan them... Chipped alone takes 2 seconds. So I added the infrastructure to skip some folders in the JARs. With Don't scan assets and data folders in the mod jars for .class files neoforged/FancyModLoader#14, this skips scanning the assets and data mod files for JARs.
• Build ModuleReferences in parallel because why not.

Performance numbers on the FC pack (single run per line so not super precise but VisualVM confirms the observations):

Baseline: 4292ms
Added root package filter without FML support: 4207ms
Added root package filter with FML support: 1136ms
Additionally make jar resolution parallel: 340ms

[marchermans]

In principal this is fine. But I have one thing to nitpick

[ichttt]

Just out of curiosity: Can you run the JarModuleFinderBenchmark? I know the set of jars is not optimal for testing the speedup of parallel scanning, but I think they still provide some value.
I like the idea of blacklisting directories that should not contain any code, but maybe we should add something in the Build Pipeline or userdev that warns if classes are present in these Directories, as it could lead to confusion why some stuff doesn't work otherwise. But tbh that is probably not needed, as it would be very weird to store classes there.

Overall, nice work!

[Technici4n]

Parallel scanning is only useful for jar metadatas that lazily compute their packages. The metadata implementations in SJH compute it eagerly (but ModJarMetadata computed it lazily and hence benefits from this speedup).

As you can see here the main hit from JarModuleFinderBenchmark is getPackages, which is not parallel with the default metadata:

[Technici4n]

Default jar metadata implementations should be changed too to benefit from parallelization, that might save over 1s of startup in some cases based on some profiles from ATM8.

[Technici4n]

Superseded by #47 and #57.