fix(cgo): Handle headers in external repositories from cc_imports

[blorente]

What type of PR is this?

Bug fix

What does this PR do? Why is it needed?

When depending on cc_import targets from external repositories, their includes attribute doesn't get resolved to execroot-relative paths. This means that we end up having -Imy/includes/dir instead of -Iexternal/external_repo_name/my/includes/dir, which leads to missing headers during compilation.

As a consequence, the -dev packages generated by rules_distroless were not being imported correctly, and we had to manually insert -isystem flags with canonical repository names.

Which issues(s) does this PR fix?

Fixes #

Other notes for review
This PR doesn't really depend on #4574, but both are needed for the project I'm working on and I'd rather that one merges first if possible, as it doesn't have a workaround.

[blorente]

I'm happy to move this somewhere else, but I'm not quite sure where the best place would be. Any suggestions?

[fmeum]

@keith Do you see a less manual way to produce the correct paths?

[keith]

fwiw i fixed the cc_import not resolving includes like cc_library in bazel 9.x bazelbuild/bazel@d948e4d

[blorente]

@keith that is so cool! I think that change makes this one unnecessary for Bazel 9.x because the external includes will be resolved correctly. Since it's also in rules_cc, I guess we should be able to just update rules_cc and consume it? I'll do some experimenting.

However, that would mean bumping the rules_cc requirement in rules_go to at least 0.2.0, I think (link). @fmeum is that something we're comfortable doing in this repository, or are we trying to not to impose dependency versions if we can avoid it? I think we can always "vendor in" the change if we need to as an alternative.

[fmeum]

No, we usually just bump dependencies when a feature in them could be useful.