Use a ClassLoader for locating resources

[melix]

Description

Before this change, the VirtualFileSystem was using a Class as a beacon to find resources. I suppose that the intent was to use Class#getResource, but in practice, it's always clazz.getClassLoader().getResource() which is used, which makes it redundant to use a class. This commit refactors the code to allow declaring which classloader to use for loading. This is important because in some cases, we don't necessarily have a Class to pass, but we do have a classloader. This should also allow more advanced scenarios with filtering classloaders for example.

Since the Class was actually never directly used, but only its classloader, this change should have 0 impact for backwards compatibility.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• org.graalvm.python.embedding.test.VirtualFileSystemTest
• org.graalvm.python.embedding.test.integration.VirtualFileSystemIntegrationTest

Test Configuration:

• Firmware version:
• Hardware:
• Toolchain:
• SDK:

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[steve-s]

FYI: what failed is ./mvnw validate -DskipJavainterfacegen=true spotless:apply. You may install https://pre-commit.com to run the full pre_commit build.

[steve-s]

I don't know what's going on with the integration (macos-latest, test_jbang_integration.py). I don't think it's anything introduced in this PR. The MacOS runners tend to have issues with memory limits when building native images, so they do fail transiently. Another PR just passed this check recently. If this is the last issue with this PR, we can consider disabling the native image build in that test when running on MacOS -- I was contemplating that for a some time already.

Btw. this log file would help us:

[jbang] [105:828] log: /var/folders/p6/nlmq3k8146990kpkxl73mq340000gn/T/jbang884856419301199466native-image

some time ago I was trying to convince actions/upload-artifact@v4 to upload it if the test fails, like it does for Linux already, but gave up after few attempts (iirc: wildcards don't work because of some permission issues, scraping the log for exact path was too hairy, ...).