[filesystem] Fix nested META-INF/versions in filesystem impl jars

[sundapeng]

Purpose

The filesystem impl modules (paimon-oss-impl, paimon-s3-impl, paimon-azure-impl, paimon-cosn-impl, paimon-gs-impl) unpack the whole jaxb-api jar into target/classes/META-INF/versions/11. Since jaxb-api is itself a multi-release jar, its own META-INF tree gets nested into the output, producing malformed entries such as:

META-INF/versions/11/javax/xml/bind/ModuleUtil.class
META-INF/versions/11/META-INF/versions/9/javax/xml/bind/ModuleUtil.class   <- nested
META-INF/versions/11/META-INF/MANIFEST.MF
META-INF/versions/11/META-INF/LICENSE.txt

Both ModuleUtil.class entries have the same internal class name javax/xml/bind/ModuleUtil but different bytecode. Any tool that scans the unpacked classes directory chokes on the duplicate. For example, JaCoCo fails with:

java.io.IOException: Error while analyzing .../META-INF/versions/11/javax/xml/bind/ModuleUtil.class
Caused by: java.lang.IllegalStateException: Can't add different class with same name: javax/xml/bind/ModuleUtil

The nesting has existed since #2658 but only surfaced after #8832 started shading META-INF/versions/11/** from paimon-oss-impl into paimon-jindo, propagating the malformed entries into that jar as well.

Changes

• Exclude the jar's own META-INF/** when unzipping jaxb-api into META-INF/versions/11. The nested META-INF/versions/9 variants were never resolvable at runtime anyway (nested multi-release directories are not a thing), so there is no functional change. The now-unnecessary META-INF/versions/11/META-INF/maven/** shade exclude is removed along with it.
• JarFileChecker now rejects any META-INF directory nested below META-INF/versions/*, so a regression fails the license check CI. The isJavaxManifest whitelist that existed to tolerate the nested jaxb manifest is removed since the path no longer occurs.

Tests

• Rebuilt all five impl modules plus paimon-jindo: no META-INF/versions/11/META-INF/** entries remain and the 121 META-INF/versions/11/javax/** classes are intact; JaCoCo Analyzer.analyzeAll on the unpacked jar contents now passes (previously threw the exception above).
• Added JarFileCheckerTest#testRejectedOnNestedMetaInfInMultiReleaseDirectory and #testAcceptedOnRegularMultiReleaseContent.

[leaves12138]

LGTM. I verified the nested META-INF fix and the new JarFileChecker regression protection, including the ZIP edge case without explicit directory entries. The paimon-ci-tools clean test suite also passes locally.