Optional toolchains

[ianthehat]

There are reasons to write rules where the exact toolchains used might vary depending on information available at analysis time.
The specific example here is that linking a go_binary needs a cc toolchain only if there was cgo in any of it's transitive dependencies.
At the moment to get the cc toolchain you have to say you need it in the rule, and then it is an error if one is not available, even if the go_binary rule was not really going to use it.
If we defer the error to the point of first access, then pure go builds will ask for a cc toolchain, but not get it, and go ahead to compile without error, whereas builds with cgo would complain if there was no cc toolchain but compile if there was.
There may be use cases where it would be nice to test whether the toolchain was available, but that's not strictly needed for this case.

[hlopko]

Another use case for this would be tools for various languages. E.g. rules_java use a tool called singlejar that is written in C++. This causes confusion in rules_java users: "Why do I need to have gcc installed when I'm only building Java??". We could rewrite the tool in Java, but then powerusers come and complain that the tool is too slow for them.

If we had support for optional toolchains, we could in theory use the knowledge that C++ toolchain is available to use the C++ tool, and in case it's not available, fallback to the Java tool.

</fairy_tale>

Cc @lberki, @iirina because they are interested :)

[lberki]

I think that automatically choosing a Java singlejar implementation would be actively harmful, because it would open the way towards accidental slowdowns that are hard to track down. Better be explicit than implicit.

[katre]

Placing this in the icebox since we have no plans to take on this work.