XRAY-145307 - Transfered logic to include plugins deps as well in maven dep tree

[gauriy-tech]

Description

The jf ca (curation audit) Maven flow supports including build-plugin transitive dependencies in the curation evaluation via the --mvn-include-plugin-deps flag (introduced in #771).

That first implementation resolved the plugin dependencies on the Go side inside mvn.go by spawning extra Maven processes (mvn dependency:resolve-plugins -B and mvn help:effective-pom) in addition to the existing maven-dep-tree invocation. This PR moves that logic into the maven-dep-tree plugin itself, so resolution happens where Aether/Maven already have full repository and lifecycle context.

The CLI now simply:

1. Passes -DincludePluginDeps=true to the existing maven-dep-tree invocation, and
2. Consumes the plugin dependencies the plugin emits under a new pluginNodes JSON section, then injects them under each module root before the curation graph is built.

This removes ~330 lines of Maven-internals logic from the CLI and makes plugin-dependency resolution more correct (proper transitive/diamond handling, lifecycle filtering) on the plugin side.

Note: Requires maven-dep-tree >= <VERSION> (jfrog/maven-dep-tree#28). The embedded JAR and mavenDepTreeVersion must be bumped together with that release.

Performance

When --mvn-include-plugin-deps is enabled, the old flow triggered three separate Maven process executions: one for maven-dep-tree, one for dependency:resolve-plugins, and one for help:effective-pom (which built an install-lifecycle plugin allow-list). Each Maven invocation pays the full cost of JVM startup, project model / effective-POM construction, and repository session setup.

By folding plugin resolution into the single maven-dep-tree run (-DincludePluginDeps=true), the two extra Maven processes are eliminated entirely — plugin deps are now resolved within the same session that already builds the project tree, reusing the already-loaded project model and repository session. This roughly cuts the Maven invocation overhead for the plugin-deps path by two-thirds and avoids redundant POM resolution work.

Testing

• Unit tests cover the new pluginNodes JSON decode (single-module, no-plugin-nodes, multi-module type-union dedup), the pluginNodesPresent signal that distinguishes "plugin doesn't support the flag" from "plugin ran but found nothing", and Classifier propagation through injectPluginDeps.
• E2E curation regression test (tests/testdata/projects/package-managers/maven/maven-curation-plugin-deps) covers the customer scenario from XRAY-144809.

• The pull request is targeting the dev branch.
• The code has been validated to compile successfully by running go vet ./....
• The code has been formatted properly using go fmt ./....
• All static analysis checks passed.
• All tests have passed. If this feature is not already covered by the tests, new tests have been added.
• Updated the Contributing page / ReadMe page / CI Workflow files if needed.
• All changes are detailed at the description. if not already covered at JFrog Documentation, new documentation have been added.

---

[gauriy-tech]

I have read the CLA Document and I hereby sign the CLA