Automatically add supports-path-mapping where applicable

[keith]

This way users don't have to pass:

--modify_execution_info=CppCompile=+supports-path-mapping,CppModuleMap=+supports-path-mapping,CppArchive=+supports-path-mapping

or know which mnemonics support it. This still does nothing unless the
overall path stripping feature is enabled

[lilygorsheneva]

I think we need a feature flag for this, based on our findings with CppLink there's probably toolchains that break with it.

[keith]

what's an example of a toolchain specific breakage?

[trybka]

I thought your finding was that this broke on apple?

When targeting macOS the debug info paths stored in the binaries are
invalid, since they encode the literal bazel-out/cfg

[keith]

that's only a problem with CppLink

[lilygorsheneva]

To clarify my previous statement:
We've had to fix at least 5 internal toolchains to support CppLink (in addition to the apple debug info paths which aren't fixed); I can't imagine CppCompile being free of such issues (in addition to the generated file issues we discussed at our last meeting).

[keith]

are you enabling this globally with --modify_execution_info today? i imagine there's a lot more value in flipping that for CppCompile than for CppLink, since there are a lot more potential actions to dedup. Also note this PR isn't doing CppCompile because that has to be done in java still bazelbuild/bazel#30485

[lilygorsheneva]

CppCompile and CppModuleMap (at least internally, maybe their behavior diverges externally) also need to share the same modify_execution_info state.

[lilygorsheneva]

More accurately, most of my testing had --modify_execution_info='CppCompile|CppModuleMap|CppCompileHeader=+supports-path-mapping'