The POMs were adjusted to the upgraded dependencies and an expected POM for `archunit-junit5` was added.

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>

Unfortunately there were some leftover docs from the time before ArchUnit released the aggregator Maven dependency for both `archunit-junit5-api` and `archunit-junit5-engine`. The section can now actually be simplified, because meanwhile there is nothing specific as compared to JUnit 4, if the aggregator artifact is used.

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>

With JDK 13 some wrongly implemented behavior of JRT path handling was fixed. I.e. by JEP-220 (https://openjdk.java.net/jeps/220) while URIs possess the shape of `jrt:/module.name/some/clazz/Name.class` the respective (virtual) file system path for JRTs supposedly has the shape of `/modules/module.name/some/clazz/Name.class`. Unfortunately ArchUnit was relying on the wrongly implemented version of `JrtFileSystemProvider` which would return a path for JRTs of `/module.name/some/clazz/Name.class`. Thus with JDK >= 13 the URI handling for JRTs was broken.
This will now be fixed by relying on pure JRT URI handling without relying on conversion to `java.nio.file.Path`. We simply split the path of a JRT URI on `/` and treat the first segment as module name, the rest of the segments as the resource/class name (e.g. `module.name` and `some/clazz/Name.class`). Note that we unfortunately cannot use `URI.getPath()` within `NormalizedUri` to retrieve the path without the schema, since `URI.getPath()` will return `null` for JAR URIs (i.e. `jar:file:/...`).

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>

fix broken JRT URL handling for JDK >= 13

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>

Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>