Add cc_runtime_linkage setting for static C++ runtime in shared libs

[walter-zeromatter]

Motivation

cdylib/dylib targets link the cc toolchain's C++ runtime (libstdc++/libc++ and the unwinder) dynamically — get_cc_toolchain_runtime_libs calls cc_toolchain.dynamic_runtime_lib() for these crate types. The runtime therefore becomes an external DT_NEEDED on the produced .so.

When shipping a self-contained shared library to a consumer that uses a different C++ stdlib (e.g. a GCC libstdc++ environment consuming a library built with an LLVM/libc++ toolchain), forcing a dynamic libc++/libc++abi/libunwind dependency is undesirable — the consumer would have to ship the producer's C++ runtime.

What this adds

An opt-in way to link the C++ runtime statically into shared libraries, so they carry no external C++ runtime dependency and the unwinder is embedded:

• //rust/settings:cc_runtime_linkage string flag — dynamic | static, default dynamic (no behavior change for existing users).
• cc_runtime_linkage attribute on rust_shared_library — auto | dynamic | static, auto (default) defers to the flag, so individual targets can opt in without flipping the global default.
• get_cc_toolchain_runtime_libs gains a linkage parameter; when static, it returns cc_toolchain.static_runtime_lib(...) for cdylib/dylib (the same call already used for all non-shared crate types). Both call sites resolve linkage via resolve_cc_runtime_linkage(ctx) (per-target attr overriding the flag).

Non-shared crate types are unchanged.

Effect (with cc_runtime_linkage = "static")

A Rust cdylib built against an LLVM/libc++ toolchain goes from:

NEEDED libc++.so.1, libc++abi.so.1, libunwind.so.1   (+ _Unwind_* UND)

to a self-contained .so: those NEEDED entries gone, _Unwind_* defined in-binary.

[ArchangelX360]

@walter-zeromatter Thank you so much for this, I faced the same issue and was working around it with a dirty patch, really appreciate the work you did here 🙏🏼