Remove dependency on Nuget.Frameworks

[nohwnd]

Remove dependency on Nuget.Frameworks by copying the relevant code into the repository and changing namespace. The Nuget.Frameworks types were not exposed in our public API directly, but we are relying on the functionality, to parse things like net5.0, net472, or any of similar framework shorthands. We also rely on all the frameworks not being explicitly stated, e.g. net11.0 or any such verison of .NET that does not exist yet.

Replace #2544

Fix #3154

The risk here is that someone is relying on us shipping Nuget.Frameworks into the bin, and not providing it themselves.

The newly added public api should not cause issues for the existing loggers because they ship together with vstest.console.

[nohwnd]

4.8? 4.8.1, 4.8.2?

[nohwnd]

$path = "S:\p\vstest3\artifacts\packages\Debug\Shipping"; (ls $path -re -fo | where { $_.FullName -notlike "*Symbols*" -and $_.Name -eq "Nuget.Frameworks.dll" }  | % fullName) -replace [regex]::escape($path)

\Microsoft.TestPlatform.17.8.0-dev\tools\net462\Common7\IDE\Extensions\TestPlatform\NuGet.Frameworks.dll
\Microsoft.TestPlatform.17.8.0-dev\tools\net462\Common7\IDE\Extensions\TestPlatform\TestHostNet\NuGet.Frameworks.dll

\Microsoft.TestPlatform.CLI.17.8.0-dev\contentFiles\any\netcoreapp3.1\NuGet.Frameworks.dll
\Microsoft.TestPlatform.CLI.17.8.0-dev\contentFiles\any\netcoreapp3.1\TestHostNetFramework\NuGet.Frameworks.dll

\Microsoft.TestPlatform.Portable.17.8.0-dev\tools\net462\NuGet.Frameworks.dll
\Microsoft.TestPlatform.Portable.17.8.0-dev\tools\netcoreapp3.1\NuGet.Frameworks.dll
\Microsoft.TestPlatform.Portable.17.8.0-dev\tools\netcoreapp3.1\TestHostNetFramework\NuGet.Frameworks.dll

which is count reduction by 2, 2 and 3 just like here.

[nohwnd]

New public api.

[nohwnd]

This returns null when it gets null or whitespace. The original check was unnecessary.

[nohwnd]

This throws in some cases when the framework is invalid, parsing will return it as Unsupported, but for example if we construct Portable 4.5 and don't specify Profile, it will construct it as supported, but throw when we ask for short name. We use short name as folder for logs, which we figure out when we have a "valid" runtime identifier, so keeping this null should be okay, we check for it in all the places where we use it, and supply the original value.