Add additional tool version details to dotnet --info

[marcpopMSFT]

Customer suggestion: dotnet/roslyn#44571 (comment)

Include the version of Roslyn, msbuild, nuget in the dotnet --info output

[maxild]

I guess that the ongoing plans to make the .NET SDK more composable (less monolithic) with optional 'building-blocks' (bundles, packs or whatever) will justify even more developing better CLI commands/verbs to inspect the acquired tree of 'core' (roslyn, nuget, msbuild, sdk-targets etc...) and composable 'optional' (aspnetcore, xamarin, blazor, etc...) 'building-blocks'.

• I know roslyn, msbuild and nuget (client) are all independently versioned today. Why not make it easy to see those versions using the CLI (SDK).
• So is visual studio (and it aligns (implicitly(!)) with the 'feature band' semver 'hack' of the SDK version x.y.znn). Are there any table showing the correspondence between vs-versions and sdk-versions?
• I guess the 'workloads' will be versioned as well somehow?

I know "this change request" is very imprecise(!), but it is a bit too abstract and difficult for me to describe given my lack of knowledge of the massive SDK.

MAIN GOAL My main goal as a user/client/customer is to better understand how milestones of the many upstream github repos "compose" into the massive SDK. There are a lot of different versioning going on:

• 16.9 (vs2019 milestone/version)
• 3.9 (roslyn milestone/version)
• 5.0.2nn (sdk milestone/version)
• etc..

Example: Will roslyn analyzers for IDExxxx and CAxxxx part of the .NET SDK since v5 be fixed wrt issue dotnet/roslyn#XXXXX (XXXXX not important) with milestone 16.9 (https://github.com/dotnet/roslyn/milestones) on Linux using (future) SDK version 5.0.200? I find it difficult to understand on Linux, but I understand that the analyzers are being migrated out of the vs2019-specific "features" assemblies, and roslyn is apparently tied to visual studio releases even though it is cross-plat...