Do not use atomic move to move jdks

[CRogers]

Before this PR

Tried this out on some very large projects internally. Kept getting this kinds of errors:

Caused by: java.lang.RuntimeException: Could not move java home
Caused by: java.nio.file.FileSystemException: /Users/callumr/.gradle/caches/gradle-jdks/azul-zulu-15.40.19-15.0.7-b7ed6f7c59131899.in-progress-c5b252e4/zulu15.40.19-ca-jdk15.0.7-macosx_aarch64/zulu-15.jdk/Contents/Home -> /Users/callumr/.gradle/caches/gradle-jdks/azul-zulu-15.40.19-15.0.7-b7ed6f7c59131899: Directory not empty
        at com.palantir.gradle.jdks.JdkManager.jdk(JdkManager.java:81)
        at com.palantir.gradle.jdks.JdksPlugin.lambda$javaInstallationForLanguageVersion$5(JdksPlugin.java:86)

It seems when you try to move a directory using ATOMIC_MOVE and the target directory exists, it fails with a FileSystemException with a message Directory not empty. Not a FileAlreadyExistsException or DirectoryNotEmptyException. At least on macos.

Additionally, the docs for ATOMIC_MOVE are a little scary:

If the target file exists then it is implementation specific if the existing file is replaced or this method fails by throwing an IOException.

😨 😨 😨

After this PR

==COMMIT_MSG==
Do not atomically move the java home directory to avoid Could not move java home: Directory not empty exceptions
==COMMIT_MSG==

Possible downsides?

[changelog-app]

Generate changelog in changelog/@unreleased

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

Do not atomically move the java home directory to avoid Could not move java home: Directory not empty exceptions

Check the box to generate changelog(s)

• Generate changelog entry

[svc-autorelease]

Released 0.7.0