Make AntClassLoader multi-release JAR aware when it deals with java.util.jar.JarFile

[basil]

See Ant Bug 62952. A straightforward backport of bz-62952 Make AntClassLoader multi-release JAR aware when it deals with java.util.jar.JarFile from Ant 1.10.6 to our forked copy of AntClassLoader.

Testing Done

I built a multi-release JAR from this demo project and stuck it into a tiny plugin, then ran the plugin in Jenkins with java -jar jenkins.war before and after this change (Java 11 runtime). Before this change, it printed "Provider: RuntimeMXBean", meaning it was using the Java 8 code from the multi-release JAR. After this change, it printed "Provider: ProcessHandle", meaning it was using the Java 11 code from the multi-release JAR.

Proposed changelog entries

Developer: Make AntClassLoader multi-release JAR aware when it deals with java.util.jar.JarFile.

Proposed upgrade guidelines

N/A

Submitter checklist

• (If applicable) Jira issue is well described
• Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change). Examples
  • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
• Appropriate autotests or explanation to why this change has no tests
• For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least 2 approvals for the pull request and no outstanding requests for change
• Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
• Changelog entries in the PR title and/or Proposed changelog entries are correct
• Proper changelog labels are set so that the changelog can be generated automatically
• If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[timja]

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!