Simple musl target build fails with incorrect Rust target

Building a fresh PyOxidizer project fails to resolve the correct `musl` Rust target, even when the Python target resolves correctly.

```
> pyoxidizer init-config-file myapp
> cd myapp
> pyoxidizer build --target-triple "x86_64-unknown-linux-musl"
resolving 1 targets
resolving target install
resolving target exe
target Python distribution for x86_64-unknown-linux-musl resolves to: https://github.com/indygreg/python-build-standalone/releases/download/20220528/cpython-3.10.4%2B20220528-x86_64-unknown-linux-musl-noopt-full.tar.zst (sha256=e00f9738488146bbf1ab39554852f203d0669145446f00bb76a6a707abb11667)
...
ensuring Rust toolchain 1.61.0 is available
fetching https://static.rust-lang.org/dist/channel-rust-1.61.0.toml.sha256
fetching https://static.rust-lang.org/dist/channel-rust-1.61.0.toml
fetching https://static.rust-lang.org/dist/channel-rust-1.61.0.toml.asc
verified SHA-256 digest for https://static.rust-lang.org/dist/channel-rust-1.61.0.toml
verified PGP signature for https://static.rust-lang.org/dist/channel-rust-1.61.0.toml
extracting rustc for x86_64-unknown-linux-gnu to /home/myusername/.cache/pyoxidizer/rust/1.61.0-x86_64-unknown-linux-gnu
found Rust package rustc version 1.61.0 (fe5b13d68 2022-05-18) for x86_64-unknown-linux-gnu
downloading https://static.rust-lang.org/dist/2022-05-19/rustc-1.61.0-x86_64-unknown-linux-gnu.tar.xz
verified SHA-256 is 21c4613f389ed130fbaaf88f1e984319f72b5fc10734569a5ba19e22ebb03abd
Segmentation fault
```

Building on Alpine Linux with an up to date `rustc` (not nightly) and the `musl` Rust target being the only local system Rust. Installed PyOxidizer via `cargo`.

```
> rustup target list
...
x86_64-unknown-linux-gnux32
x86_64-unknown-linux-musl (installed)
x86_64-unknown-netbsd
...
```

The segfault is likely due to attempting to use the `glibc` based Rust (no `glibc` compatibility enabled locally).

Explicitly setting the Rust target in various ways has also been tried (limited personal experience here), such as via setting Starlark globals under the `VARS` dict via the `.bzl` and via the `pyoxidizer` CLI, for example:

```
> pyoxidizer build --target-triple "x86_64-unknown-linux-musl" --var BUILD_TARGET_TRIPLE "x86_64-unknown-linux-musl"
```

which resulted in the same output as above. Also tried removing the `--target-triple` setting and using "BUILD_TARGET" in place of "BUILD_TARGET_TRIPLE", as hinted at in [some documentation](https://gregoryszorc.com/docs/pyoxidizer/main/pyoxidizer_config_type_python_distribution.html#default-python-distribution).

Using the system Rust _does_ work, however, and produces a build that runs as expected under `pyoxidizer run`:

```
> pyoxidizer build --target-triple "x86_64-unknown-linux-musl" --system-rust
```

This is functional for now, but using a specified, self-managed Rust is preferable.

Start by reproducing the `pyoxidizer build --target-triple x86_64-unknown-linux-musl` case on Alpine and compare it with the working `--system-rust` invocation. Trace the Rust toolchain resolution and target selection; done means the managed Rust path selects the musl target without attempting the incompatible glibc toolchain or segfaulting.

Written by the indexing model from the issue text.