Artifact resolves differently based on java version

I'm not sure if this should be raised here or directly on coursier, but we've noticed that in some cases artifacts resolve differently based on if the `java` on the PATH is 8 or 11.

Here's a minimal example:

```
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

RULES_JVM_EXTERNAL_TAG = "4.2"
RULES_JVM_EXTERNAL_SHA = "cd1a77b7b02e8e008439ca76fd34f5b07aecb8c752961f9640dea15e9e5ba1ca"

http_archive(
name = "rules_jvm_external",
strip_prefix = "rules_jvm_external-%s" % RULES_JVM_EXTERNAL_TAG,
sha256 = RULES_JVM_EXTERNAL_SHA,
url = "https://github.com/bazelbuild/rules_jvm_external/archive/%s.zip" % RULES_JVM_EXTERNAL_TAG,
)

load("@rules_jvm_external//:defs.bzl", "maven_install")

SPRING_BOOT_VERSION = "2.6.0"

maven_install(
name = "maven",
artifacts = [
"org.slf4j:slf4j-api:1.7.32",
"org.springframework.boot:spring-boot-starter-data-jpa:%s" % SPRING_BOOT_VERSION,
],
fetch_sources = True,
repositories = [
"https://repo1.maven.org/maven2",
],
maven_install_json = "@//:maven_install.json",
)
```

On java 8, it picks slf4j-api 1.7.32, but on java 11 it detects a conflict and picks 2.0.0-alpha1

```
❯ java -version
openjdk version "1.8.0_312"
OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-macos-aarch64) (build 1.8.0_312-b07)
OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-macos-aarch64) (build 25.312-b07, mixed mode)
❯ bazel run @unpinned_maven//:pin
INFO: Analyzed target @unpinned_maven//:pin (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target @unpinned_maven//:pin up-to-date:
bazel-bin/external/unpinned_maven/pin
INFO: Elapsed time: 0.138s, Critical Path: 0.00s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action
INFO: Running command line: bazel-bin/external/unpinned_maven/pin external/unpinINFO: Build completed successfully, 1 total action
Successfully pinned resolved artifacts for @maven, /Users/richard.stephens/pinning_test/maven_install.json is now up-to-date.

❯ cat maven_install.json|grep -A 2 conflict_resolution
"conflict_resolution": {},
"dependencies": [
{
```

```
❯ java -version
openjdk version "11.0.13" 2021-10-19 LTS
OpenJDK Runtime Environment Zulu11.52+13-CA (build 11.0.13+8-LTS)
OpenJDK 64-Bit Server VM Zulu11.52+13-CA (build 11.0.13+8-LTS, mixed mode)
❯ bazelisk run @unpinned_maven//:pin
Starting local Bazel server and connecting to it...
INFO: Analyzed target @unpinned_maven//:pin (19 packages loaded, 143 targets configured).
INFO: Found 1 target...
Target @unpinned_maven//:pin up-to-date:
bazel-bin/external/unpinned_maven/pin
INFO: Elapsed time: 9.295s, Critical Path: 0.01s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action
INFO: Running command line: bazel-bin/external/unpinned_maven/pin external/unpinINFO: Build completed successfully, 1 total action
Successfully pinned resolved artifacts for @maven, /Users/richard.stephens/pinning_test/maven_install.json is now up-to-date.

❯ cat maven_install.json|grep -A 2 conflict_resolution

"conflict_resolution": {
"org.slf4j:slf4j-api:1.7.32": "org.slf4j:slf4j-api:2.0.0-alpha1"
},
```

Start by reproducing the minimal example with Java 8 and Java 11, using the shown maven_install configuration and @unpinned_maven//:pin target. Compare the resulting maven_install.json conflict_resolution entries and determine why slf4j-api resolves differently. Done means dependency resolution is consistent across the reported Java versions, with a regression check for this example.

Written by the indexing model from the issue text.