Fix zig cc/c++ mishandling of -u (undefined symbol) linker flag

[electronjoe]

Closes #243

The -u SYMBOL flag tells the linker to treat SYMBOL as undefined, forcing it to be resolved from archives or shared libraries. This is a standard linker feature used to:

• Force inclusion of specific archive members (e.g., static initializers, plugin registration, constructor functions)
• Pull in coverage/profiling runtime symbols (e.g., __llvm_profile_runtime)
• Ensure weak symbol overrides are linked
• Implement plugin architectures that require specific entry points

Currently, Zig's cc/c++ driver misinterprets -u SYMBOL - it attempts to open SYMBOL as a filename rather than passing it to the linker. This breaks any toolchain or build system that relies on this flag.

This is a known Zig bug tracked at:
https://codeberg.org/ziglang/zig/issues/30613

The fix (https://codeberg.org/ziglang/zig/pulls/30749) is pending merge. I'll post on the issue and merge request at Zig just to +1 the need for a fix - and I'm not sure whether you want to integrate a work around here in hermetic_cc_toolchain or not vs waiting for an upstream fix.

This patch works around the issue by transforming -u SYMBOL into -Wl,-u,SYMBOL, which explicitly passes the flag through to the linker.

Discovered while debugging bazel coverage failures in a mixed C++/Rust repository (minimal reproduction at https://github.com/electronjoe/bazel-cpp-rust-codecov). This repo uses hermetic_cc_compiler and rules_rust -> rustc passes -u __llvm_profile_runtime for coverage instrumentation. If you would like to reproduce the original issue, you can open a codespace from the repo, bazel coverage //..., observe success - then roll back this patch in the repo and try again to observe the failure mode.

[CLAassistant]

All committers have signed the CLA.