Fix: resolve relative classpath elements against the fork's working dir

[cwegener-79]

When Surefire uses a manifest-only JAR to pass the classpath (default on Windows
and for long classpaths), Class-Path entries in the manifest are relative to the
manifest JAR's parent directory - a temp directory, not the fork's working directory.

A relative additionalClasspathElement (e.g. ../resources) was written as-is into
the manifest, where the JVM resolved it against the temp directory instead of the
fork's workingDirectory, silently pointing at the wrong location.

Fix: JarManifestForkConfiguration now resolves relative classpath elements against
the fork's working directory before computing their manifest-relative representation.
All resolveClasspath() implementations receive the resolved working directory as a
new parameter. In direct classpath mode (ClasspathForkConfiguration) no change in
behavior is needed as the JVM already resolves -cp entries against its own CWD.

Adds unit test (ForkConfigurationTest) and integration test
(AdditionalClasspathForkIT / additional-classpath-relative-workdir) to guard
against regression.

Testing

Unit tests pass (mvn clean install).
Integration tests (-PrunIts) could not be executed due to proxy restrictions in my build environment.

Known build issue

mvn clean install fails with the RAT plugin reporting unapproved licenses on generated files inside target/ subdirectories (e.g. checkstyle-cachefile, spotless-index, .plxarc). This appears to be a pre-existing gap in the RAT configuration — target/ is not explicitly excluded. The following addition to the <excludes> block in the root pom.xml would fix it:

<exclude>**/target/**</exclude>

Build can be verified in the meantime with:

mvn clean install -Drat.skip=true

---