refactor: replace jfrog CLI runtime dependency with SDK-backed execution

[Ompragash]

Summary

This change removes the plugin’s runtime dependency on the external jf binary and replaces the execution path with JFrog Go SDK and command-library integrations.

The result is a plugin binary that:

• runs without requiring JFrog CLI to be installed alongside it
• preserves the existing plugin contract and supported behavior surface
• remains portable across target OS and architecture builds, including Linux, Windows, and macOS

Maven and Gradle remain host-tool dependent by design:

• Maven uses mvn from PATH
• Gradle uses gradlew when present, otherwise gradle from PATH
• missing host tools now fail with explicit user-facing errors

Architectural Changes

Runtime execution

• replaced shell-driven JFrog CLI invocation with SDK-backed runtime execution
• added an isolated runtime context for:
  • temporary JFROG_CLI_HOME_DIR
  • project config generation
  • inline spec materialization
  • cert seeding and cleanup
• moved generic upload/download and build-info flows onto direct Artifactory service-manager usage

Auth handling

• split auth construction into two distinct paths:
  • direct client-go auth for SDK-backed service-manager operations
  • wrapper-compatible ServerDetails for Maven and Gradle registration
• direct SDK flows now use the real ApiKey field instead of routing API keys through AccessToken
• retained the wrapper-path API-key workaround only where jfrog-cli-core still requires ServerDetails

Maven and Gradle

• kept Maven and Gradle on JFrog’s Go command packages rather than shelling out to jf
• preserved server registration, project config generation, Windows defaults, and build-info publication sequencing
• added explicit host-tool error normalization for missing Maven and Gradle executables

Behavioral Compatibility

This refactor preserves the plugin’s supported behavior surface, including:

• source/target upload and download flows
• spec-based execution via PLUGIN_SPEC and PLUGIN_SPEC_PATH
• pattern, wildcard, recursive, flat, and target-props handling
• build-info collection and publication
• build scan, promote, cleanup, add-build-dependencies, and build-discard flows
• platform-specific certificate handling for container and binary execution

The plugin no longer depends on JFrog CLI at runtime, but it does still depend on host build tools for Maven and Gradle operations.

Follow-up Hardening Included

This PR also addresses the post-migration runtime issues that surfaced during review:

• propagates context.Context through the SDK-backed generic and build-info paths
• joins cleanup failures instead of dropping secondary errors
• replaces misleading shell-splitting behavior with a best-effort parser plus warning fallback
• simplifies Maven config construction and removes redundant download-spec state
• removes the last dead legacy shell execution path that still hardcoded context.Background()

Dependency Notes

The JFrog module set remains pinned to source-compatible pseudo-versions for jfrog-cli-artifactory, jfrog-cli-core, jfrog-client-go, and build-info-go.

This is an upstream constraint, not a local preference:

• the currently compatible wrapper modules still depend on unreleased combinations
• the latest tagged jfrog-cli-artifactory release is missing APIs used by this migration path

A TODO comment is included at the wrapper compatibility seam to revisit this once upstream publishes a fully tagged compatible stack.

Validation

Validated with:

• go test ./...

Coverage added around:

• auth construction
• joined cleanup behavior
• context preflight cancellation
• host-tool error normalization
• spec generation behavior
• best-effort shell parsing
• Maven config defaults and deployer clearing

Risk / Caveats

• generic and build-info flows now honor context preflight and SDK-level request context
• Maven and Gradle wrappers still do not expose full mid-flight cancellation hooks
• end-to-end live Artifactory validation across every command permutation was not performed in this change set; this PR validates the runtime contract and unit-tested behavior, not full external integration coverage