Use systemPath for system-scoped dependencies instead of remote resolution (#27)

[jozanek]

Fixes #27

Problem

When a dependency has <scope>system</scope> (with a <systemPath>), the plugin tried to resolve it from remote Maven repositories. Since system-scoped jars live on the local filesystem and aren't published to any repo, this produced spurious Downloading from central: … attempts and [ERROR] FAILURE …:system / Could not resolve …:system log lines — the symptom reported in #27 (e.g. jdk.tools:jdk.tools:1.8 pulled in transitively by hadoop-annotations on Java 8).

Fix

In MojoImplementation, when building the resolution modules, branch on scope: for Artifact.SCOPE_SYSTEM, use the file Maven already set from <systemPath> instead of issuing a remote ArtifactRequest. If that file is genuinely absent (e.g. tools.jar on JDK 11+), the artifact is skipped with a warning rather than aborting the whole bloopInstall (the dependency was never resolvable anyway). The compile/runtime classpath is unaffected — it still comes from Maven's own getCompileClasspathElements(), which already includes the system jar for the module that declares it.

Notes

• System scope is not transitive in Maven, so a system dep only surfaces on the module that declares it — never on downstream consumers. The fix and tests reflect this.
• The pre-existing try/catch in resolveArtifact already prevented a hard crash by swallowing the failed remote fetch; this change removes the wasted remote round-trips and the misleading error logging, and uses the provided path as intended.

[tgodzik]

LGTM!