Multiple Tooling Profiles per Project

### Is your feature request related to a problem? Please describe

https://github.com/rustdesk/rustdesk/discussions/9412

This idea might sound complex but if tackled carefully, it could make up for a nice addition to `asdf` (hopefully without overcomplicating this, otherwise, delightful utility). The suggestion is to support multiple `.tool-versions` files, or multiple mutually-exclusive tools versions per project, allowing one of them to be activated at any given time.

**USE CASE:** A major barrier to contributing to the RustDesk project has been the complexity of the build process. This discourages community contributions to an otherwise fantastic project while maintainers remain overburdened and unable to [offer support](https://github.com/rustdesk/rustdesk/discussions/763).

Currently, the project requires managing version control for:
- flutter
- rust
- vcpkg
- cmake
- nasm
- (maybe) ruby

The challenge lies in determining the correct combination of versions to build the app. At the moment, the GitHub Action [workflow files](https://github.com/rustdesk/rustdesk/blob/dd004f1a2d91cac774ecfe61ac22d28f1df5694b/.github/workflows/flutter-build.yml#L28) in the repository serve as the single source of truth.

Although the [build documentation](https://rustdesk.com/docs/en/dev/build/) for RustDesk does not currently mention `asdf`, I identified it as a clean solution for managing tool versions. However, RustDesk might require different versions of tools depending on tasks—for example, generating Dart code from Rust versus performing the final build.

Currently, the developers are encouraged to run the GitHub actions or use Docker for the build, which I have not tried to be completely frank (I am building the MacOS X app on an Apple Silicone MacBook pro with Xcode and all).

This complexity led me to consider the possibility of extending `asdf` to support this workflow natively.

Thank you for your time and any constructive feedback you can provide!

### Describe the proposed solution

Extend the `.tool-versions` syntax to support the following capabilities:

1. Allow specifying alternative versions for a single plugin. (not consumed by the plugin but by `asdf`)
2. Enable switching between pre-defined sets of plugin versions for specific workflows.

The challenge would be to preserve compatibility and maintain the tool's simplicity. As an alternative, symbolic links could achieve similar functionality but are less elegant.

### Describe similar `asdf` features and why they are not sufficient

Currently, multiple local versions are handled by some plugins (e.g. Python) rather than being managed by the tool itself.

### Describe other workarounds you've considered

Create symbolic links:

`.tool-versions` links to `.tool-versions-build1` or `.tool-versions-build2` based on workflow.

script `activate_tooling.sh`:
```bash
ln -sF ".tool-versions-build$1" .tool-versions
```

## Usage

### Switch to `build1`

Use:
```bash
./activate_tooling.sh 1
```

After than executing `ls -la .tool*` gives:
```bash
lrwxr-xr-x@ 1 orwa staff 21 Jan 17 16:44 .tool-versions -> .tool-versions-build1
-rw-r--r--@ 1 orwa staff 59 Jan 17 16:42 .tool-versions-build1
-rw-r--r--@ 1 orwa staff 57 Jan 17 16:39 .tool-versions-build2
```

And typing `rusc --version` gives `1.75.0`

### Switch to `build2`

Use:
```bash
./activate_tooling.sh 2
```

After than executing `ls -la .tool*` gives:
```bash
lrwxr-xr-x@ 1 orwa staff 21 Jan 17 16:44 .tool-versions -> .tool-versions-build2
-rw-r--r--@ 1 orwa staff 59 Jan 17 16:42 .tool-versions-build1
-rw-r--r--@ 1 orwa staff 57 Jan 17 16:39 .tool-versions-build2
```

And typing `rusc --version` gives `1.81.0`

Start by reviewing the proposed .tool-versions syntax and the activate_tooling.sh workaround, then compare them with the linked RustDesk GitHub Actions workflow and existing asdf behavior. Done would mean defining a compatible approach for alternative tool versions and mutually exclusive project profiles without overcomplicating current version selection.

Written by the indexing model from the issue text.