LF_BUILDINFO introduces non-determinism to Windows rlib builds

The changes from #113492 have introduced a source of non-determinism in our rustc invocations, which causes cache invalidations for us in Buck since the output often changes hashes.

The root issue here seems to be that LF_BUILDINFO now contains an absolute path to rustc.exe, which is not consistent for our use-case in Meta (our build machines use https://github.com/facebook/dotslash in order to download rustc to a temporary directory which is not stable across hosts). The LF_BUILDINFO entry is present in every rlib artifact we produce.

Details

1. Build an rlib crate on windows
2. ar x foo.rlib to look at the rcgu.o files
3. llvm-pdbutil dump -all foo-<hash>.foo.<hash>-cgu.0.rcgu.o

Contents for our Buck built rlib look like:

0x100C | LF_STRING_ID [size = 152] ID: <no type>, String: C:\remote_execution\dotslash_cache\keyed_blake3\dc\ef\<hash>\data\bin\rustc.exe

The problematic string ends up embedded in the object files within the rlib archive, introducing non-determinism in our build outputs.

I'd like to adjust this by proposing one of a few ideas:

1. Amending LF_BUILDINFO to accept a relative path (or user-defined path) to rustc.exe. E.g. -Zbuildinfo_exe_path=rustc.exe or similar.
2. Omit LF_BUILDINFO's command & command line args entirely, reverting back to pre- #113492 behavior. E.g. -Zomit_buildinfo_args or similar.
3. Something else?

Would any of these options make sense to pursue as a PR?

Start by reproducing a Windows rlib build and inspect its rcgu.o members with ar x and llvm-pdbutil dump -all, focusing on the LF_BUILDINFO string containing the rustc.exe path. Compare artifacts built from different temporary rustc locations, then determine and document a chosen behavior that removes the path-based non-determinism while preserving the intended build information.