Define a distribution constraint setting

A common trick with Bazel rules is to download prebuilt SDK's and use that as toolchains. However, it is a mistake to assume that keying which SDK to download on the `@bazel_tools//platforms:os` value will work in every case. SDK's are seldom self-contained and often assume a specific glibc, or filesystem layout. On Linux, not all distributions are alike. On macOS, not all versions are alike. So we need finer grained platform info.

One idea would be to add a generic `distribution` constraint setting, in addition to the existing `os` and `cpu` constraint settings. The `distribution` setting could be used to choose the SDK format as well. For example, while the default might be a binary distribution as commonly distributed by upstream (official Go SDK's, official GHC binary distributions, etc), alternatives for obtaining a working toolchain might be to use Snappy, AppImage, Nix or Flatpak, depending on what is available or what the user prefers.

Not all toolchain distribution methods work on all platforms. Binary distributions seldom work on NixOS because the dynamic linker is not at a known location. Conversely, using Nix, be it on macOS or Linux, requires first that Nix be installed (same from Snappy etc). One might argue that Flatpak, Nix or Snappy should be an `os` constraint value. But that's very inconvenient. For example, on macOS dynamic libraries are called `libfoo.dylib` rather than `libfoo.so`. Rules want to deal with macOS specifics, while also letting the user choose among several possible sources fo toolchains. To allow that with just one constraint setting, we'd have to define many constraint values, like `osx`, `osx_nix`, `linux`, `linux_nix` etc.

Nix is available as a distribution method both on Linux and on macOS. Flatpak, Snappy, AppImage and the like are for the moment Linux-specific. But could well likewise be multi-platform in the future. Defining a new `constraint_setting` would avoid the combinatorial explosion in constraint values that would otherwise be needed if we continue having just `@bazel_tools//platforms:os`.