.NET Tools work natively in arm64 environments and feel first-class on all platforms

[marcpopMSFT]

We want to invest in improving dotnet tools but there are a lot of issues. Use this epic to track the ones with higher priorities:

• When installing a .NET local tool, create the tool manifest if one does not exist #15254
• dotnet tools do not support differing entitlements than the dotnet muxer on Mac #23640
• dotnet tool install doesn't understand multi-arch systems or TFM requirements #26417
• dotnet tool install should implicitly do dotnet tool update (same for dotnet workload install/update) #28664
• RID aware .NET tools #28923
• dotnet tools targeting Windows APIs #12055
• Download tool packages from NuGet feeds directly, instead of implicitly restoring #31134
• A new option to allow dotnet tool install should return exit code 0 if tool is already installed #10310 - this is a posix-ism that we should reevaluate
• macOS dotnet CLI path for global tools is bad - Installer issue #23165
• [Proposal] .NET Tools should default to running on the latest available Runtime #30336
• dotnet tool restore interactive doesn't prompt for DeviceFlow since .NET 6 SDK #22987

[augustoproiete]

@baronfel @marcpopMSFT Here is a couple suggestions you might want to track in this epic:

• Consistent way to run dotnet tools regardless if installed as global or as local tool #14626
• dotnet tool list should list global tools as well #4264
• Installing a dotnet global tool should ignore the global.json in the current folder #14721