Dependency conflict for jna (with testcontainers:1.15.0-rc2)

Using the current testcontainers-core release candidate triggers the following dependency conflict:

./gradlew :dependencyInsight --configuration testCompileClasspath --dependency net.java.dev.jna:jna

> Task :dependencyInsight
Dependency resolution failed because of conflict(s) on the following module(s):
   - net.java.dev.jna:jna between versions 5.5.0 and 5.2.0

net.java.dev.jna:jna:5.5.0
   variant "compile" [
      org.gradle.status              = release (not requested)
      org.gradle.usage               = java-api
      org.gradle.libraryelements     = jar (compatible with: classes+resources)
      org.gradle.category            = library

      Requested attributes not found in the selected variant:
         org.gradle.dependency.bundling = external
         org.gradle.jvm.version         = 14
   ]
   Selection reasons:
      - By conflict resolution : between versions 5.5.0 and 5.2.0

net.java.dev.jna:jna:5.5.0
\--- com.github.docker-java:docker-java-transport-zerodep:3.2.5
     \--- org.testcontainers:testcontainers:1.15.0-rc2
          \--- org.testcontainers:spock:1.15.0-rc2
               \--- testCompileClasspath

net.java.dev.jna:jna:5.2.0 -> 5.5.0
\--- org.rnorth.visible-assertions:visible-assertions:2.1.2
     \--- org.testcontainers:testcontainers:1.15.0-rc2
          \--- org.testcontainers:spock:1.15.0-rc2
               \--- testCompileClasspath

I'm unsure whether the fix should be in docker-java-transport-zerodep to not expose jna or if jna should be excluded for visible-assertions. Maybe you have even better solutions. So this time no instant pull request, but I'm happy to create one for however and wherever you prefer the fix to be :)

Comienza reproduciendo el conflicto con ./gradlew :dependencyInsight --configuration testCompileClasspath --dependency net.java.dev.jna:jna. Inspecciona los metadatos de dependencia de docker-java-transport-zerodep y visible-assertions a través del grafo de dependencias de Testcontainers y, después, verifica que la solución elegida elimine el conflicto de versiones de JNA sin romper el classpath de pruebas.