Fix relative symlink handling in write_atomic

[cuishuang]

What does this PR try to resolve?

Fixes #17361.

cargo_util::paths::write_atomic follows symlinks before performing an atomic write. However, fs::read_link returns a relative target exactly as stored in the symlink.

The returned target was previously used directly, causing subsequent filesystem operations to interpret it relative to Cargo's process working directory. This could make the write fail or overwrite an unrelated file.

This change resolves the target against the symlink's parent directory:

resolved_path = path.parent().unwrap().join(target);

Path::join preserves absolute targets, so the existing behavior for absolute symlinks is unchanged.

How to test and review this PR?

A new unit test creates a symlink with a relative target in a directory different from the process working directory. The test verifies that:

• the actual target receives the updated contents;
• the symlink remains a symlink;
• the stored relative target remains unchanged.

I ran:

cargo +1.97.1 test -p cargo-util
cargo fmt --all -- --check

All 12 unit tests and the cargo-util doc-test passed.

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @epage, @weihanglo
• @epage, @weihanglo expanded to epage, weihanglo
• Random selection from epage, weihanglo