fix: Support '=' and '$SYSROOT' in linker scripts and inputs

[Blazearth]

Resolves #2719 by properly handling GNU ld sysroot prefixes (= and $SYSROOT) across linker scripts, command-line inputs, and search paths.
Check maybe_forced_sysroot before checking if the linker script is inside the sysroot in maybe_apply_sysroot, fixing resolution for in-sysroot scripts specifying = or $SYSROOT.
Support the default empty sysroot when --sysroot is not configured by stripping the prefix without altering absolute/relative path structure.

[davidlattimore]

We've just merged a change to address this, so this line is no longer needed.

[Blazearth]

removed it .

[davidlattimore]

Can you check if we're able to correctly create a save-dir when a path like $SYSROOT/tmp/input.o is passed to the linker, but no --sysroot is supplied? Specifically, does the save-dir load $D/tmp/input.o (i.e. a saved file inside the save-dir) or does it try to load /tmp/input.o from outside the save-dir (i.e. break the encapsulation of the save-dir).

[Blazearth]

Sure! previously, save_dir only expanded forced sysroot prefixes for -L directories, not positional input arguments. When $SYSROOT/tmp/input.o was passed without --sysroot, write_args was emitting the literal $SYSROOT/tmp/input.o into the response file / run-with script, which caused the replay to load /tmp/input.o from outside the save directory and broke encapsulation.
I've added forced-sysroot handling for positional inputs in save_dir.rs::write_args, so it now resolves the path and emits $D/tmp/input.o.

[davidlattimore]

Does the save-dir code correctly handle paths like this in linker scripts? How about when --sysroot isn't set?

[Blazearth]

Thanks for pointing this out. I've pushed an update with save-dir integration tests covering both = and $SYSROOT prefixes, with and without --sysroot.
I also replaced global string substitution with position-based edits to avoid overlapping path replacements.