Add a platform rule to simplify toolchain selection logic

[katre]

Tracking issue for the work to add platforms and better toolchain selection to Bazel.

See the design document at https://docs.google.com/document/d/1-G-VPRLEj9VyfC6VrQBiR8To-dZjnBSQS66Y4nargGM/edit?ts=57df9619#heading=h.al54v2ddwqzv for more details.

[katre]

I've gotten bad about tagging this issue in commits, so mentioning them here for tracking:

34efd79 Rename ToolchainLookup rule to ToolchainType, to better explain the usage of the rule.
be5f25c Rename the ToolchainProvider to a more accurate name (and free up the name for the new ToolchainProvider).
96580a4 Expose platform-related providers to Skylark.
edbeafe Adding toolchain provider and function to Skylark.
5dc81a2 Add toolchain_rule to enable rule authors to define toolchains.

[jmhodges]

Thank you for writing this up!

I was wondering about a possible use case.

The Go race detector is turned on when -race is passed to the Go compiler and linker to the Go target you're running and all of its dependencies. This turns out to be fairly difficult to get right, and is pretty clearly a fit for the platforms. That's not my use case but set up for it.

It would be nice if we didn't have to create new targets that flipped on the Go race detector on for itself and its deps, but instead could just pass in a CLI flag that chose the platform with the race detector flag set on its compiler and linker.

Is that a feature that will exist?

[jmhodges]

Oh, jeez, right on the next page is the answer laid out in the tensorflow example: yes.

Thanks again for writing all this down. Very helpful while I consider what to do about bazelbuild/rules_go#167

[katre]

The platform rules exist, and work is continuing in #4442 , so closing this issue.