Add check/warning for Linux 'mixed install' to `dotnet --info` implementation

[baronfel]

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

See this livestream for a good example of the problem.
Users on Linux (and other platforms, but Linux especially due to our distribution decisions) very often run into problems installing and managing .NET versions. The most common expression of these problems is

• user installs MS or Distro-provided .NET packages, which install 'globally' to a system-wide location and set the /etc/dotnet/install...... files
• user wants to try a preview, and since we and our distro partners may not provide preview packages, our instructions guide them to use the install-scripts and/or direct tar downloads + configuration
• part of these configuration steps is to set PATH and DOTNET_ROOT
• user ends up with a PATH that finds the dotnet muxer from the system installs first, but uses that muxer against the SDKs installed in DOTNET_ROOT - resulting in mixed and broken installations

Describe the solution you'd like

We should add detection and warning of this scenario to dotnet --info. Roughly, the behavior for the detection should be

* If the current `dotnet.exe` muxer is inside global_install_root (as determined by the [original spec](https://github.com/dotnet/designs/blob/92bdc899eb90529abb717e1684ba6e7c6907c1f4/accepted/2020/install-locations.md) and the [per-architecture addendum](https://github.com/dotnet/designs/blob/92bdc899eb90529abb717e1684ba6e7c6907c1f4/accepted/2021/install-location-per-architecture.md) we have for global installs)
* and the DOTNET_ROOT environment variable is set to somewhere outside of that same root
* `dotnet --info` should add a section that emits warning message telling the user they are in a mixed-mode, and linking to additional documentation/guidance
  * Linux: https://learn.microsoft.com/en-us/dotnet/core/install/linux-package-mixup
  * Other platforms: None found, but tell the user that the dotnet found on their PATH isn't the same one that exists in their DOTNET_ROOT, suggest they have a PATH-ordering problem