[Epic] Various quality of life issues when running a hackathon experiment

I recently did a hackathon effort over the weekend in which I tested the latest LLM tech with dotnet. Here are a handful of issues that I believe are important to help people adopt these tools more easily and are generally known in the community.

I did this experiment with .NET 8, macOS Sequoia 15.0, and a can of diet coke handy.

- [ ] .NET installer should automatically add dotnet to the PATH.

From a fresh install after nuking everything, here is what was suggested just to get `dotnet` to run in various contexts throughout this experiment:

```
export PATH=$PATH:/usr/local/share/dotnet
export DOTNET_ROOT="/usr/local/share/dotnet"
export PATH=$PATH:$DOTNET_ROOT
export PATH="$PATH:/Users/jondouglas/.dotnet/tools"
export PATH="$PATH:/usr/local/share/dotnet/x64"
```

My expectation would be to only have to add one single path which all of these infer from. I had to do 5 different ones just to get a typical ASP.NET Core, EF, Tools, etc setup. I'm on a ARM machine and have no idea why x64 is here either, but I needed it to get SOMETHING to work.

- [ ] CPM is not compatible with `dotnet test`.

Wanting to adopt CPM from the beginning led to a major challenge where I cannot add a `dotnet test` template nor "fix" it to be able to work with CPM due to implicit pkg references coming from the SDK (I believe).

My expectation is that I could easily on-board ANY .NET SDK template to CPM as a best practice.

- [ ] `dotnet run` doesn't open a localhost browser by default.

While the default is mixed in various ecosystems, my expectation of `dotnet run` was to visually see something. I think there might be potential to give both defaults with two different verbs. `dotnet serve` or `dotnet dev` seem like good opportunities to provide a "user-friendly" mode. Other potential opportunities to these verbs might be default hot reload/watch and debugging capabilities.

My expectation is to have a single CLI command that enables the inner-development loop by launching a browser that I will stay in while I am constantly manipulating files and wanting to see these changes show up on save.

- [ ] `global.json` blocks completely.

While pulling down various repositories to mimic behavior from, I'd often be stuck unable to compile nor run their code because they included a `global.json` with a specific version in it.

When I remove this file, their projects happily compiled with my .NET 8 SDK anyway as I was unwilling to go download .NET 6 or something else.

I propose that .NET SDK has a better management experience of these "environments". A good concept in python land is the concept of virtual environments. A new command like `dotnet environment` could use a `.dotnet-version` (akin to `global.json`) which can infer the .NET SDK/Runtime requested by the project and ensure compatibility with the global environment. If there is no compatibility, a "virtual environment" can be created in which some helpful CLI management commands like `dotnet environment install 6.0.XXX` may install the required tooling in the background and a user can set their global environment via `dotnet environment global 8.0.XXX` or similar

My expectation was that the latest stable version of .NET SDK/Runtime would allow me to run virtually any project, and that is true if I remove `global.json`

- [ ] Empowered CLI commands.

Not many of the CLI commands support great "piping" nor empowered error messages that help you resolve the issue at hand. An extremely helpful tool in these cases is machine-readable output which isn't always there for various commands.

My expectation is that just about every command could be utilized with piping and provide helpful output that a LLM can take in to resolve a future problem.

- [ ] Integrate EF tools into SDK.

This may be a controversial one, but having used these tools for about a decade, I've been unsure why Entity Framework commands could not be integrated into the dotnet CLI formally? Having to download separate tools to use the premiere ORM is a strange experience. Just about every command could be folded into dotnet SDK and put behind some type of reference conditional to work? `dotnet migrations add`, `dotnet database update`, etc. To ensure this isn't a standardization/favortism thing, a flexible model for tools that would like to extend this pattern might make sense.

My expectation is that I can use common database commands directly in `dotnet` without having to install separate tools and follow additional steps/tutorials just to get those to work out of the box.

...More to come, these are fresh!

(I do not expect any answers or explanations, just logging these things down as I encounter them)