Multi-release support in ..builder.ClasspathJar?

Method `org.eclipse.jdt.internal.core.builder.ClasspathJar.initializeModule()` tries to find module-info.class in a version-specific folder.
* This support seems incomplete as it cannot find module-info.class in a version lower than the single version in field `#compliance` (e.g., when requesting version 24, whereas only version 17 provides module-info.class). If no exact match is found, we directly fall back to the unversioned source folder.
* actually `compliance` is assigned only in the constructors of sub class `ClasspathMultiReleaseJar`
* Also `initializeModule()` is overridden in `ClasspathMultiReleaseJar`

This looks like the implementation in `ClasspathJar` is both wrong and unneeded 😄

While at it, we might want to double check, which version is actually set as `compliance`, I see it derived from the version-sourcefolder mapping in a multi-release *project*, and many call paths passing `JavaCore.NO_RELEASE`.

Start by comparing org.eclipse.jdt.internal.core.builder.ClasspathJar.initializeModule() with the override in ClasspathMultiReleaseJar, then trace where compliance is assigned in the subclass constructors and where JavaCore.NO_RELEASE is passed. Verify version selection for a requested release when only a lower version-specific module-info.class exists. Done means the redundant or incorrect handling is resolved and multi-release module lookup uses the intended compliance consistently.

Written by the indexing model from the issue text.