Fix clang-scan-deps PATH lookup and lld detection on macOS

[srikantharun]

Summary

This PR fixes two related toolchain configuration issues:

1. clang-scan-deps PATH lookup (fixes #553)

Problem: clang-scan-deps path was hardcoded by assuming it's in the same directory as the compiler:

cc_str = str(cc)
path_arr = cc_str.split("/")[:-1]
path_arr.append("clang-scan-deps")
deps_scanner = "/".join(path_arr)

Solution: Use PATH lookup via which() first, with fallback to the compiler directory for backward compatibility.

2. lld path detection on macOS (fixes #499)

Problem: _find_linker_path() used the last quoted path line from stderr:

invocations = [line for line in result.stderr.splitlines() if line.startswith(" \"")]
linker_command = invocations[-1]  # This picks up warning lines!

When lld emits warnings (e.g., ld64.lld: warning: directory not found for option -L/usr/local/lib), the warning appears after the linker invocation, causing the detection to fail.

Solution: Look for the specific linker invocation line by matching linker patterns (ld.lld, ld64.lld, ld.gold, gold) instead of blindly using the last line.

Test plan

• Verify clang-scan-deps is found via PATH when available
• Verify lld detection works on macOS with Homebrew lld that emits warnings
• Verify backward compatibility when clang-scan-deps is only in compiler directory

[trybka]

Can you rebase and merge your PR? I think the LLD changes have already been addressed in #516 but the clang-scan-deps fixes might still be valuable.

cc: @PikachuHyA @fmeum

[PikachuHyA]

I’d prefer to look for clang-scan-deps in the same directory first, and only fall back to searching in PATH if it isn’t found. The reason is that I want to ensure, as much as possible, that clang and clang-scan-deps are from the same version.

Would this change break your workflow?