Fix stale .attach_pid files left in cwd if target process dies before attachment completes in Hotspot

[Krishnapriya-RS94]

This PR backports OpenJDK below fixes to prevent stale .attach_pid files from being left in application current working directories.
JDK-8214300
JDK-8228343

Why

When attaching to a JVM process using the HotSpot attach mechanism, ByteBuddy creates an .attach_pid<pid> file in the target process's current working directory (accessed via /proc/<pid>/cwd/). If the target process dies or crashes after the attach file is created but before the attachment completes, the cleanup in the finally block fails because

• The /proc/<pid>/cwd/ symlink disappears when the process dies.
• The cleanup code tries to delete the file using the symlink path
• The deletion fails silently, leaving the .attach_pid file orphaned in the application's working directory

How

This PR implements the same fix used in OpenJDK:

• Create the attach file first via the /proc/<pid>/cwd/ symlink (container-safe, per JDK-8228343)
• Immediately resolve to canonical path after creation (resolves symlinks to actual filesystem path)
• Use canonical path for cleanup in the finally block (works even if /proc/<pid>/ disappears)

Example:

Application running in: /opt/app/myapp/
Attach file created: /proc/12345/cwd/.attach_pid12345 → /opt/app/myapp/.attach_pid12345
Process 12345 dies → /proc/12345/ disappears
Cleanup tries: /proc/12345/cwd/.attach_pid12345 (fails - symlink gone)
Result: /opt/app/myapp/.attach_pid12345 remains as stale file

Backported OpenJDK fixes:
Fix: Use canonical path for cleanup
JDK-8214300
Commit: ec1f0263

Fix: Attach failure for target container processes if canonical path is used for file creation
JDK-8228343
PR: #4418

[raphw]

Instead of moving this to a method, could you just add a line with:

attachFile = attachFile.getCanonicalFile();

Wrap this in an try-catch block for IOException and ignore the exception, as resolving a canonical file can fail.