Move the extracted JDK into the tool-cache instead of copying it - #1206

Description:

Installing a JDK writes it to disk twice. Every distribution extracts the archive into RUNNER_TEMP and then calls tc.cacheDir, which recursively copies the whole tree into RUNNER_TOOL_CACHE. For a 200-600MB JDK that is a few hundred megabytes of pure redundant I/O on every cache miss, and it is the single most expensive step in the install path - considerably more than the vendor metadata requests people usually suspect.

This PR addresses that, plus the extraction step next to it.

1. Move instead of copy (cacheJdkDir)

New helper in src/util.ts, replacing tc.cacheDir at all 15 distribution installers. The extraction directory and the tool-cache normally live on the same filesystem, so the copy can just be a fs.renameSync. The helper mirrors the destination layout tc.cacheDir produces exactly (including semver.clean(version) || version and the arch default) and writes the .complete marker itself, so tc.findAllVersions / findInToolcache keep resolving entries unchanged.

It falls back to the original tc.cacheDir copy when:

• RUNNER_TOOL_CACHE is unset,
• the source is not a real directory. lstat is deliberate here: renaming a symlinked source would put the link itself in the tool-cache, leaving a dangling JAVA_HOME once RUNNER_TEMP is cleaned, and the .complete marker would make it look healthy forever,
• the rename fails. The upstream toolkit explicitly comments "do not move. move can fail on Windows due to anti-virus software having an open handle on a file", and a cross-device tool-cache raises EXDEV. A rename is atomic, so a failure leaves the source fully intact for the fallback to copy.

2. Faster extraction

extractJdkFile now hands tarball decompression to pigz when the runner provides it, and extracts Windows zips with the bundled %SystemRoot%\System32\tar.exe instead of tc.extractZip, which shells out to PowerShell's Expand-Archive (typically several times slower for a JDK-sized archive). Both paths fall back to the stock extraction, cleaning up the abandoned directory first so a failure does not double peak temp usage.

Worth a careful look:

• The move changes a copy-children-into-dest into a rename-dest semantic. I diffed this against the real cacheDir / _createToolPath / _completeToolPath in @actions/tool-cache to confirm the resulting layout is identical, and the symlink case above is the one place they genuinely differ, which is why it falls back.
• pigz is skipped if its resolved path contains whitespace, since tar word-splits --use-compress-program.
• Verified end to end by running the built action against Temurin 21 and Zulu 17: the extraction directory drops to 0B (proving the move), the .complete marker and directory layout match, java -version works, and a subsequent run resolves from the tool-cache with no network.

Related issue:
N/A

Check list:

• Ran npm run check locally (format, lint, build, test) and all checks pass.
• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.

Tests: 20 new cases in __tests__/util-install.test.ts covering the move, marker creation, replacing an existing entry, version/arch normalization parity with tc.cacheDir, and each fallback path (missing tool-cache root, symlinked source, rename failure with no stale marker left behind, pigz failure and cleanup, whitespace in the pigz path, Windows tar.exe failure and cleanup). Full suite is 1272 passing.