-Clinker-plugin-opt should propagate external linkage + default visibility symbols to the `MustPreserveSymbols` retained by LTO

(Summarized from https://g-issues.fuchsia.dev/issues/529449843)

When creating a shared library that contains a mix of LTO'd an non-LTO'd code, it's possible for rust to not retain symbols from the non-LTO'd code which should be retained since we expect to export them from the shared library. This occurs specifically when using -Clinker-plugin-opt. The scenario is LTO will remove some code in the LTO'd bitcode which would call some function in the non-LTO'd code. Now the LTO'd bitcode has no reference to that function, so it's okay to not extract that symbol from the non-LTO'd rlib. When rustc drives the link (ie. without -Clinker-plugin-lto), rustc populates the MustPreserveSymbols which forces these symbols to be retained anyway.

While we can circumvent this by just not using -Clinker-plugin-lto, this prevents a bunch of cross-language optimizations which we'd like. It seems like the right thing to do is have rust somehow propagate this information to LLD when it drives the link. Not sure of what the machinery for doing that would look like though.

Start by tracing how -Clinker-plugin-opt handles MustPreserveSymbols when linking a shared library with mixed LTO and non-LTO code. Reproduce the symbol-retention failure described in the issue and compare it with rustc-driven linking without -Clinker-plugin-lto. Done means the external-linkage and default-visibility symbols are propagated so LLD retains them.