staticRead fully resolves symbolic links
### Description

Hello,

Recently, I've developed Bazel rules for Nim - [rules_nim](https://github.com/kczulko/rules_nim). I wanted to create the example of how to use those rules based on a well know Nim ecosystem project like `nimble`. It turns out that `nimble` is using `staticRead` function which fully resolves symbolic links created by Bazel which in the end leads to successful build but not hermetic one. It means that output artifact is not a result of a compilation process of precisely specified input files. Input files of a `nimble` build action don't contain `nimble.nimble` file but such file is being accessed by the Nim compiler probably through fully resolving symbolic link under the hood of `staticRead`.

Detailed description:
1. [This nim_module target](https://github.com/kczulko/rules_nim/blob/9771a36be8628ad42a142d366c50664ab27db0b9/e2e/nimble/src/BUILD.bazel#L17) which is a set of nim files doesn't contain [nimble.nimble file](https://github.com/kczulko/rules_nim/blob/9771a36be8628ad42a142d366c50664ab27db0b9/e2e/nimble/nimble.nimble#L3).
2. nimble's file `common.nim` reads the version from `nimble.nimble` during compile time ([see here](https://github.com/kczulko/rules_nim/blob/9771a36be8628ad42a142d366c50664ab27db0b9/e2e/nimble/src/nimblepkg/common.nim#L25)) so that running `--version` echoes the following output:
```python
$ bazelisk run //src:nimble -- --version
...

nimble v0.16.3 compiled at 2024-12-05 16:10:12
git hash: 9771a36be8628ad42a142d366c50664ab27db0b9
```
3. Build is successful although `nimble.nimble` is not a declared input of a build procedure - it looks like `staticRead` fully resolves the symlink.
4. Here's the set of files that form a `nimblepkg` `nim_module` (there's no `nimble.nimble`):
```python
$ bazelisk build //src:nimblepkg
INFO: Analyzed target //src:nimblepkg (1 packages loaded, 36 targets configured).
INFO: Found 1 target...
Target //src:nimblepkg up-to-date:
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/checksums.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/cli.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/common.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/config.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/deps.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/developfile.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/displaymessages.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/download.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/downloadnim.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/forge_aliases.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/init.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/jsonhelpers.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/lockfile.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/nim.cfg
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/nimbledatafile.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/nimblesat.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/nimenv.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/nimscriptapi.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/nimscriptexecutor.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/nimscriptwrapper.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/options.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/packageinfo.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/packageinfotypes.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/packageinstaller.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/packagemetadatafile.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/packageparser.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/paths.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/publish.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/reversedeps.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/sha1hashes.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/syncfile.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/tools.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/topologicalsort.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/vcstools.nim
  bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/version.nim
INFO: Elapsed time: 0.087s, Critical Path: 0.02s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action
```
5. `common.nim` is indeed a symbolic link under `bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/` dir:
```python
$ file bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/common.nim
bazel-bin/src/nim_module_nimblepkg/src/nimblepkg/common.nim: symbolic link to /home/kczulko/rules_nim/e2e/nimble/src/nimblepkg/common.nim
```

Bazel is a build tool that promotes reproducible, sandboxed build actions with aggressive caching strategies. One of the key ideas which allows that are the symlinks. If that's possible, can you please analyze whether Nim compiler could resolve paths based on symbolic links rather than fully resolving those links? I've made a small check of a similar situation in python (2.7) and I've observed the expected results - path was not fully resolved and traversal happened on the symlink tree level:
```python
$ tree
.
├── symlink-tree
│   ├── a
│   │   └── b
│   │       └── main.py -> ../../../tree/a/b/main.py
│   └── file.txt -> ../tree/file.txt
└── tree
    ├── a
    │   └── b
    │       └── main.py
    └── file.txt
$ cat tree/a/b/main.py
with open("../../file.txt") as f:
    print(f.read())
```

Thanks in advance,
Karol

### Nim Version

arch: `x86_64-linux`
nim versions: both `2.2.0` and `2.0.12`
bazel version: 
```python
$bazelisk --version
bazel 7.4.1
```
OS: NixOS 
```python
$ nixos-version
24.05pre-git (Uakari)
```

### Current Output

_No response_

### Expected Output

```text
Build failure e.g.:

/home/kczulko/.cache/bazel/_bazel_kczulko/da01d39d256a1e9fb65efe5559265008/execroot/_main/bazel-out/k8-fastbuild/bin/src/nim_module_nimblepkg/src/nimblepkg/common.nim(25, 29) Error: cannot open file: ../../nimble.nimble
```

### Known Workarounds

Copying whole nim files subset seems like a workaround. However this is in contrast of aggressive caching approach that bazel promotes. This would mean that every time `nim_module` would have to remove and copy the whole files tree. That would constantly invalidate cached build action and generate poor build performance.

### Additional Information

_No response_