[4.2.0 Cherry-pick] Fixes incorrect install names on darwin platforms

[csmulhern]

JUSTIFICATION:
--incompatible_macos_set_install_name is broken without this change. This cherry-pick applied cleanly without modifications.

ORIGINAL COMMIT:
b06f495

RELEASE NOTES:

• Fixes --incompatible_macos_set_install_name not correctly setting install names.

OLD COMMIT MESSAGE:

#12304 added support to bazel for setting install names for dynamic
libraries on darwin platforms. This would set LC_ID_DYLIB to
@rpath/{library_name}, so that RPATH would be used to locate these
libraries at runtime. However, the code was using a utility method that
assumed the library name was mangled, which is often not the case. Given
that the output path should already have been determined with the
mangled or unmangled name, we should be able to just use the base name
of the artifact. The test that was added in #12304 has been updated to
actually use dynamic libaries, and passes with the changes made in this
commit.

Closes #13427.

PiperOrigin-RevId: 377504015

[csmulhern]

Linking to the 4.2.0 Release Issue (#13558) for tracking purposes.

CC: @katre.

[katre]

Looks good, thanks. I'll merge this when the tests pass.

[katre]

I spoke too soon: looks like the tests are failing. Please investigate and let me know when this is ready.

[csmulhern]

The issue with the failing test is that a cc_library without linkshared=1 (libfoo in the test) is being dynamically linked, and then the dylib is not found at runtime due to an incorrect install name. It seems that:

1. There was a change made after the cut that changed the linking behavior of libfoo in the test case.
2. Install names are still not being set correctly in some cases.

Given the above, let's skip the cherry-pick.