Default exec=target assumptions on toolchains are too general when trying to use custom toolchains

The musl_cross_compiling example doesn't work out of the box when compiling _on_ linux-gnu _for_ linux-musl.

In that case, we need two rust toolchains - one for our exec tools which compiles linux-gnu -> linux gnu, and another for our target output which compiles linux-gnu -> linux-musl. When doing a build currently, the correct C++ toolchain is chosen in each case, but the linux-gnu -> linux-gnu Rust toolchain is selected for both target platforms. This is incorrect - the linux-gnu -> linux-gnu toolchain should not be selected for linux-gnu -> linux-musl because it has a constraint it doesn't satisfy.

I believe this is because in a few places we hard-code an assumption basically that "any Linux toolchain is good enough for any Linux target".

One of these places is here:
https://github.com/bazelbuild/rules_rust/blob/8b977b5f7020fc3a3b3bbc318e414269014f126a/rust/repositories.bzl#L984-L988

where we prevent users from telling us "this toolchain actually has a more specific target platform than you expect" - we should swap the order of these `if`-branches.

Another is here: https://github.com/bazelbuild/rules_rust/blob/8b977b5f7020fc3a3b3bbc318e414269014f126a/rust/repositories.bzl#L870

where we encode an assumption that every toolchain is appropriate for targeting its own exec triple.

Fixing these two is sufficient for building example that depends on libc.

See https://github.com/illicitonion/rules_rust/commits/musl-from-linux/ for an example of making this work - the top commit does some hacky changes to break these assumptions, but someone who knows more about the toolchain set-up and/or has more time to think about the consequences of these changes should work out what the best real fix for these problems is.

cc @matte1