Improving the experience of using tools with a runtime install

The following recent issue got me thinking about acquiring tools via the SDK and deploying them to a runtime environment.

https://github.com/dotnet/dotnet-docker/discussions/6090 

I just did the following:

```Dockerfile
FROM mcr.microsoft.com/dotnet/sdk:9.0 AS sdk

RUN dotnet tool install --global dotnet-runtimeinfo --version 1.0.5

FROM mcr.microsoft.com/dotnet/runtime:9.0

COPY --from=sdk /root/.dotnet/tools/.store/dotnet-runtimeinfo/1.0.5/dotnet-runtimeinfo/1.0.5/tools/netcoreapp3.1/any/ /dotnet-runtimeinfo
ENTRYPOINT ["dotnet", "/dotnet-runtimeinfo/dotnet-runtimeinfo.dll"]
```

Not: It's unlikely you'd do this to run the tool as an `ENTRYPOINT`. I just did that a proof of concept / validate the test.

This all works, but it's quite ugly. You have to pin the version number in order to be able to predict the path. It's not possible to capture an EXE this way.

I then remembered about `--tool-path`.

The Dockerfile can be vastly simplified!

```Dockerfile
FROM mcr.microsoft.com/dotnet/sdk:9.0 AS sdk

RUN dotnet tool install --tool-path /dotnet-runtimeinfo dotnet-runtimeinfo

FROM mcr.microsoft.com/dotnet/runtime:9.0

COPY --from=sdk /dotnet-runtimeinfo/ /dotnet-runtimeinfo
ENTRYPOINT /dotnet-runtimeinfo/dotnet-runtimeinfo
```

Not so fast.

I then tried another experiment with the resultant `--tool-path` image.

```bash
rich@mazama:~/dtest$ docker run --rm -it --entrypoint bash toolstest
root@29011ca7d434:/# ls /dotnet-runtimeinfo/
dotnet-runtimeinfo
root@29011ca7d434:/# mkdir /test
root@29011ca7d434:/# mv /dotnet-runtimeinfo/dotnet-runtimeinfo /test
root@29011ca7d434:/# ls /test
dotnet-runtimeinfo
root@29011ca7d434:/# ./test/dotnet-runtimeinfo
The application to execute does not exist: '/test/.store/dotnet-runtimeinfo/1.0.5/dotnet-runtimeinfo/1.0.5/tools/netcoreapp3.1/any/dotnet-runtimeinfo.dll'.
```

I did something that seems reasonable on the surface but is very much not. Clearly, that same structure is still there and very difficult to reason about.

```bash
root@5f5d3858905d:/# find /dotnet-runtimeinfo/ | wc -l
23
```

Go and Rust both have somewhat similar experiences that result in binaries that have all the character of normal binaries. I think tools would have much more general utility if they had a mode that supported that.

Ironically, we go to great lengths to build a turnkey system that has great UX, but then we still end up with the following on macOS and Linux.

```bash
You can add it to the current session by running the following command:

export PATH="$PATH:/root/.dotnet/tools"
```

This issue isn't itself a proposal, but documenting that tools satisfy a very narrow use case and were not designed for scenarios that (A) we know that users need, and (B) that match what are platforms offer.