Support AOT tools in .NET tools

[baronfel]

Tools of all kinds benefit from fast execution speeds, so compiling them for AOT makes sense. .NET Tools are a very easy way to distribute tools, so it would seem natural that tools be able to be AOT compiled. There are a few hurdles that would need to be cleared first, though:

• Tools would need to support a notion of RID-specificity
• We would need to be able to indicate that certain already-compiled binaries should be packaged as the RID-specific version of a tool
• on tool install, we'd need to be able to detect if a tool was already-compiled and not create the apphost shim for that tool

Another, potentially more crazy idea might be to on-demand AOT a tool for the current platform on tool install. This could require data that we don't already have packaged in the tool, and might require dependencies like a C/C++ compiler that aren't part of our already-expressed dependency tree for the SDK.

[knocte]

potentially more crazy idea might be to on-demand AOT a tool for the current platform on tool install.

IMO it's not that crazy. It would save lots of disk space on the nuget side of things (not to mention simplifying the solution for this github issue), and if you think about it, a user that installs a dotnet tool is in most cases a dev, so it's not too insane to require him to have some compiler tools to be able to have his tool optimized for speed.

(Just my 2 cents)

[KalleOlaviNiemitalo]

If a user installs a global tool by using an x86 .NET SDK on an x64 operating system, then would dotnet tool install AOT-compile that tool for x86, for x64, or both?