Don't make wrong assumptions about the toolchain based on env

Right now a lot of assumptions about the toolchain are made based on the (arch, os, env) part of the triple that are not always true:

• target_env = "musl" means that a static libc is available
• target_env = "musl" and dynamic linking means that unwinding is done by libgcc
• target_env = "musl" and static linking means that unwinding is done by libunwind

In my opinion there should be more specific variables. For example:

• target_libc - the name of the C library, if any. For example, "glibc", "musl", "newlib", "bionic", "msvc".
  Right now this seems like the role of target_env, however some people have proposed using different target_envs like "dynmusl": https://github.com/rust-lang/rust/issues/59302. "eabihf" and "gnueabihf" are also used.
• target_builtins - the name of the C builtins library, if any. For example, "libgcc", "compiler_rt". I'm not sure what the situation is with MSVC. For some strange targets it might make sense to leave this unset, indicating that the compiler_builtins crate should provide them instead.
  Right now the compiler_builtins crate seems to be used even when the toolchain can provide the builtins.
• target_unwind - the unwinding implementation that should be used. For example, "libunwind", "libgcc", "libc++abi". For some strange targets this might be left unset, meaning that unwinding is not supported.
  Right now musl uses libgcc when doing dynamic linking and libunwind when doing static linking.

It should be possible to specify what the toolchain provides and Rust shouldn't #[link] or reimplement:

• target_provides = "libc" - the libc crate shouldn't try to find -lc. Instead it should assume that the toolchain provides a libc compatible with target_libc.
• target_provides = "libm" - might be useful if the math stuff is split off of std.
• target_provides = "builtins" - The compiler_builtins crates should not provide anything.
• target_provides = "unwind" - The libunwind crate should assume that the unwinding functions that would be provided by target_unwind will magically appear in the binary.

For some targets it makes sense to bundle static libraries inside rlibs. These are the targets where it is expected that the toolchain used by rustc will be unable to/not used to produce C executables. I think this should be indicated by setting target_vendor = "rust".

The issue names no files, tests, or entry points. Begin by mapping how target_env, target_vendor, compiler_builtins, libc, and libunwind currently determine toolchain behavior; done means those assumptions are replaced by explicit target metadata for libc, builtins, unwinding, and provided libraries.