[gcov] LLVM 17+ change in `.gcda` path formation when using `-fprofile-dir`

# Summary / Background

I’m upgrading a project from LLVM 16 to LLVM 20 and noticed a change in how Clang forms .gcda paths for GCC-style coverage (`--coverage`). In LLVM 17+(a07b135ce0c0111bd83450b5dc29ef0381cdbc39 and f0303bd67d32b41d6502d2ff5fa825a9d21acf96), it seems that:

1. `-fprofile-dir=` is prepended even when the computed path is already absolute (e.g., under PWD=/proc/self/cwd).

https://github.com/llvm/llvm-project/blob/1322e71f2baac9d7cfa77cfa5345bfffbff74cf7/clang/test/Driver/coverage.c#L53-L55

2. `-fprofile-dir=.` now resolves to a path that includes an absolute compilation directory segment, breaking our downstream expectation that .gcda outputs remain purely relative.

## Minimal example for (2):
```bash
clang -### --coverage WORKSPACE/src/a.cpp -o WORKSPACE/build/a.o -fprofile-dir=.
```

### LLVM 16 result:
```
-coverage-notes-file=/home/USER/WORKSPACE/build/a.gcno
-coverage-data-file=./WORKSPACE/build/a.gcda
```

### LLVM 20 result:
```
-coverage-notes-file=/home/USER/WORKSPACE/build/a.gcno
-coverage-data-file=./home/USER/WORKSPACE/build/a.gcda
```

⚠️ Please note the leading `./ `combined with an absolute segment in the .gcda path in LLVM 20.

https://github.com/llvm/llvm-project/blob/1322e71f2baac9d7cfa77cfa5345bfffbff74cf7/clang/lib/Driver/ToolChains/Clang.cpp#L679-L693

I’m trying to confirm whether these are intentional semantics.

# Environment

- OS: Linux x86_64
- Toolchains compared:
- Clang/LLVM 16.0.6
- Clang/LLVM 20.1.8
- Coverage mode: GCC-style coverage (--coverage)

Reproduce the LLVM 16 and 20 commands from the issue first. Read clang/lib/Driver/ToolChains/Clang.cpp around lines 679-693 and the related cases in clang/test/Driver/coverage.c at lines 53-55. Done means determining whether the changed .gcda path behavior is intentional and documenting or regression-testing the resulting semantics.

Written by the indexing model from the issue text.