Version manager

I propose a new tool that takes care of

* Installing multiple versions of MESA
* Installing the corresponding MESA SDK version required for that MESA version
* Installing shmesa (or take over some of its duties)
* Selecting the right version of MESA at runtime

For now, I will not focus on potential ways of implementing this, but rather how a user is expected to use this tool. Details and names of commands can of course be changed for the actual implementation. This is inspired by tools such as [rustup](https://rustup.rs/) and [uv](https://docs.astral.sh/uv/).

### Installation

On the MESA installation instructions, the first step listed after the prerequisites would become "Run the following in your terminal, then follow the onscreen instructions."

```shell
curl --proto '=https' --tlsv1.2 -sSf https://installer.mesastar.org | sh
```

This would then do the following (paths are assumed for a normal linux install):

* Install the installer itself in `~/.local/share/mesastar/bin`.
* Add `~/.local/share/mesastar/bin` to the user's `PATH` (e.g. by adding `export PATH=~/.local/share/mesastar/bin:$PATH` to the right shell initialization script)

Ideally, all of these steps are customizable. The script should tell the user what it plans to do.

Example: rustup installer options

```
Welcome to Rust!

This will download and install the official compiler for the Rust
programming language, and its package manager, Cargo.

Rustup metadata and toolchains will be installed into the Rustup
home directory, located at:

/home/vincentva/.rustup

This can be modified with the RUSTUP_HOME environment variable.

The Cargo home directory is located at:

/home/vincentva/.cache/cargo

This can be modified with the CARGO_HOME environment variable.

The cargo, rustc, rustup and other commands will be added to
Cargo's bin directory, located at:

/home/vincentva/.cache/cargo/bin

This path will then be added to your PATH environment variable by
modifying the profile files located at:

/home/vincentva/.profile
/home/vincentva/.config/zsh/.zshenv

You can uninstall at any time with rustup self uninstall and
these changes will be reverted.

Current installation options:

default host triple: x86_64-unknown-linux-gnu
default toolchain: stable (default)
profile: default
modify PATH variable: yes

1) Proceed with standard installation (default - just press enter)
2) Customize installation
3) Cancel installation
```

After the installer has installed itself, it can then install the latest version of MESA and install the corresponding SDK. These would be downloaded and extracted to

* `~/.local/share/mesastar/sdk/SDK_VERSION`
* `~/.local/share/mesastar/mesa/MESA_VERSION`

and `./install` would be executed.

### Starting to use MESA

Once the installer (and potentially a base version of MESA is installed), the user would have access to a single command called `mesa`. The installation/getting started instructions should direct the user to create their first workdir.

```
mesa workdir new NAME_OF_WORKDIR
```

This will copy the workdir template from the default (more on that later) MESA version to `NAME_OF_WORKDIR`. This could be a new implementation or just delegate to `shmesa` located in this default MESA version. At that point we are basically at the normal setup and the user may continue to use MESA as they please.

### But wait, what about `MESA_DIR` and `MESASDK_ROOT`?

At this point, there have been no instructions for the user to set the `MESA_DIR` and `MESASDK_ROOT` variables. How does MESA now know where to find itself then? The main Makefile in the workdir would essentially contain (or be patched to support older MESA version):

```make
MESA_DIR ?= $(shell mesa environment print-mesa-dir)
MESASDK_ROOT ?= $(shell mesa environment print-sdk-dir)
```

We should allow the user to override these variables (in case they don't want to use the installer or work without the SDK).

### Managing multiple MESA versions

The main selling point for a tool such as this would be to manage multiple versions of MESA at the same time. It would allow you to do things such as

```
mesa install MESA_VERSION
mesa set-default MESA_VERSION
```

As an example, you may `mesa list` could output

```
25.12.1 (default)
24.03.1
15140
```

Commands such as `mesa workdir new` would take an optional `--version` argument that would allow the user to select a specific MESA version. If this argument is not present, the default version is used. When a workdir is created, a file `.mesa-version` would be copied as well, which would allow `mesa environment` to output the right `MESA_DIR` and `MESASDK_ROOT`. If you don't have the right MESA version installed, it could offer to install it.

### Power user/developer

For power users or developers, this tool should be optional. If your environment requires a specific compiler, prevents you from using the SDK, ... it should still be possible to install and customize MESA as is currently possible.

Thoughts? I mostly wanted to just document these ideas and gather feedback. I am not planning to start working on this soon.

Start by reviewing the installation instructions, the main Makefile, and the existing shmesa entry point mentioned in the proposal. Define the user-facing command and version-selection behavior before implementation; done would mean an agreed design with clear installation, workdir, environment, and customization requirements.

Written by the indexing model from the issue text.