[native_toolchain_c] Add support for fetching and connecting multiple toolchains

[nikeokoronkwo]

When working on #2792, I noticed that a user may have multiple toolchains present on their system, and it'd make sense if support was provided for fetching all possible toolchains on a user's system and using the best suitable choice of tools for their project.

A best suitable toolchain would be one that is:

• Connected: The tools are connected together and therefore operate under the same version and standard constraints (rather than having one tool meant for a different version of clang being used).
• Complete: The major motivation for this issue is that the swiftly toolchain (i.e. the tools that come bundled with a swift distribution) are usually incomplete and only contain a few of the necessary tools (in this case, just clang and ld.lld). We should, therefore, pick a toolchain that is complete (i.e. the user's default rather than swiftly's).
• Works for the given architecture: It is possible that a given compiler on a user's system compiles to a different architecture, which may not be the most suitable for the project.
• Covers the largest scope, unless otherwise specified: Unless the user chooses to override the toolchain he/she wants to use (I do not know if this is already a feature or not), the tool resolver should pick the toolchain that covers the largest scope of projects (i.e. prefer standard, cross-compiling tools than specific architecture ones (i.e. those prepended by triples). This isn't usually an issue, but in the event they are symlinked, I feel we should check incase.

This issue proposes this, by using which -a (Windows: Get-Command -All) and then possibly resolving dependent tools for each of the tool instances found, and then selecting a good combination, falling back to default behaviour (pick any) if a suitable combination was not found.

See #2800 (comment) and #2800 (comment) for more information

[dcharkes]

Yes, I had this thought as well:

• [native_toolchain_c] Tool groups #857

This issue proposes this, by using which -a (Windows: Get-Command -All) and then possibly resolving dependent tools for each of the tool instances found, and then selecting a good combination, falling back to default behaviour (pick any) if a suitable combination was not found.

Yes!