Linking two `.a` libraries that have the same name ignores one of them

Hello folks. I hit this issue while trying to wrap some C code into Rust (as one does) via FFI for [Kythe][ky]. Kythe has as C library `//kythe/cxx/common:status`, which has `@com_google_absl//absl/status` as a dependency (so both are `libstatus.{a|so}`, just in different directory paths). What I discovered is that at link time, the two above libraries get linked like so:

```
path/to/cclang ... blah ... \
-L path/to/com/google/absl/status \
-L path/to/kythe/cxx/common/status \
-l status \
... blah ...
```

This setup ends up with `//kythe/cxx/common:status` shadowing `@com_google_absl//absl/status`. A consequence is that the linker then sees no symbols from the latter library (e.g. `absl::Status::Status`), and fails the link. I think this is an issue for bazel, since short local names for library targets are the norm (as we expect that labels will disambiguate).

This in turn means that large projects are increasingly likely to have libraries with conflicting local names (e.g. `status`). The end result (failed link) is confusing.

The workaround is fairly easy if you control at least one of the labels: give the library you control a different name. But I suspect this gets increasingly impractical as the number of repos and libraries grow. [Here is an example][ex] of what I needed to do to make the link step succeed.

This issue does not happen when linking C++, I suspect because the C++ toolchain refers to libraries by their full path.

Sorry I don't have a small repro yet. I wanted to get the bug description out there so people understand what they need to do if they hit this issue.

What options (beside playing with renames) are available?

[ex]: https://github.com/filmil/kythe/pull/1/commits/5cc19ba36151513abebb103dd5d4b94b7e40d40f
[ky]: https://github.com/filmil/kythe/pull/1