Description
Currently we collect labels in various places (scala_library/scala_binary/scala_import/etc) and propagate them onwards.
This is valuable since when we want to report to the user on a problem with a transitive dependency (unused deps/strict deps) we have a meaningful label and not just a file path.
Java rules also used a similar (but different) approach but have moved a year or more ago to a different approach.
Their current approach "stamps" the jar upon creation* with its label (k/v in the manifest.mf) and so if they ever need to report (which is the rare case) then and only then they pay the (higher) price of opening the jar and reading the manifest to improve the user reporting.
This doesn't actually happen on jar creation but implicitly on ijar creation.
This means that we need to explicitly stamp our outputs for scala_import and scala_macro_library since they don't go through ijar. java_common has a special API for this.
Note that some tests will fail with this change since our existing mechanism allows us to remap labels (if bar exports foo then when someone uses bar the outputs of foo will be listed as bar). This is valuable in having facade targets for logical libraries.
After lengthy discussions it was agreed that the solution for this pattern should be in a smarter tool that will use bazel query to find the fact that bar exports foo and will add bar to the caller.
Also the changes in #716 are needed.