pkg_tar rule break the symlink and cause link error at runtime on MacOS

The attribute `include_runfiles = True` is useful for me since I would like to keep things organized as they are in workspace dir tree.

However, I found the pkg_tar rule keep two copys of dynamic lib:
* One in the dir tree as we declare them by BUILD file.
* Another is located in _solib_darwin_arm64 for MacOS (_solib_k8 for Linux).

In the project workspace, the one in bazel-bin/_solib_darwin_arm64 is actually a symlink to the one in dir tree. However, in package tar both are duplicated files.

It introduces linking error when I run the binary. (The binary links the .so lib with relative path by using @loader_path)

This behavior makes no sense to me.

Could anyone tell if it's desired behavior or not? many thanks.

An simple example:
```
- bin/executable
- lib
|- module_a
|- a.so
|- module_b
|- deeper_dir
|- b.so
```
We have executable deps on b and b deps on a.

After pack with pkg_tar, we have the following in tar ball:
```
- _solib_darwin_arm64
|- encoded_path_to_a
|- a.so. # no longer a symlink to lib/module_a/a.so
|- encoded_path_to_b
|- b.so. # no longer a symlink
- bin/executable
- lib
|- module_a
|- a.so
|- module_b
|- deeper_dir
|- b.so
```
When running the executable binary, it try to link `_solib_darwin_arm64/encoded_path_to_b/b.so`, which is no longer a symlink but the same content with the origin one.
Therefore every relative path broken when b.so trying to load a.so by relative path.

Start with the pkg_tar rule and its include_runfiles=True behavior, then reproduce the example on macOS and inspect the generated tar contents. Compare the _solib_darwin_arm64 entries with the original lib paths and run the packaged executable to confirm the relative-link failure. Done means the intended symlink behavior is established and the runtime-linking outcome is verified.

Written by the indexing model from the issue text.