Resolve relative manifest targets like the runfiles directory does

[fmeum]

The target of a runfiles manifest entry is an absolute path, except for unresolved symlinks (ctx.actions.declare_symlink), whose target Bazel copies into the manifest verbatim: SourceManifestAction#writeFile writes metadata.getUnresolvedSymlinkTarget(), which may be relative. In a runfiles directory, sandboxes and SymlinkTreeHelper#createRunfilesSymlinks create such an entry textually ("Unresolved symlinks are created textually"), so the file system resolves it relative to the directory containing the symlink.

A manifest-based lookup returned that raw target instead, i.e. a path relative to the current working directory. rlocation thus either failed or, worse, returned an unrelated file that happened to exist relative to the working directory.

This change makes it so that a relative target resolves as an rlocation path relative to the directory of its entry and looks that up in the manifest again, which is what resolving the symlink in a materialized runfiles directory amounts to. Targets that escape the runfiles root cannot be resolved this way and are reported as missing, as are cycles, which are broken after 32 levels.

The test runs the same lookups against both backends: write_relative_symlink_target_layout emits the same set of unresolved symlinks as a manifest and as a materialized runfiles directory, and assert_relative_symlink_target_lookups asserts that each resolves to the same file. Before this change, the directory-backed half passes and the manifest-backed one fails on its first assertion. The only case in which the two cannot agree is a relative target that leaves the runfiles tree, which the file system resolves against the directory's parent; the manifest offers no way to reach it, so it is reported as missing.