Method to support `dotnet test --no-build` CLI scenario

[admalledd]

I understand per #1 comment and a few other historical issues that there isn't a desire to fully support all the CLI tooling (especially the end complexity of dotnet build and dotnet publish). However, behind the scenes dotnet test is likely simple enough to allow to work. I have achieved this in two ways:

1. conditional logic in each of my .csproj files
2. experimental minor change in MSBuild.SDK.SystemWeb\sdk.targets on my local machine

Fundamentally the issue is that for reasons you cannot set -p:VSToolsPath=... as part of the dotnet test ... CLI, it gets overridden by something else in the upstream SDKs/tooling.

My current workflow (via workaround (1) above):

1. MSBuild (full-framework/VS's MSBuild) the SLN
2. dotnet test $SLN --no-build -p:VSToolsPathOverride=... (other args)

Notably that I am not asking for dotnet test to build the code (though that seems to work? outside my expertise to be sure though), just support/trick it enough that the test projects which reference/depend on the SystemWeb projects can do their things. While this still requires users to go "above and beyond" what is normally expected to run the dotnet test and such CLI tools, for those of us willing to add a few -p override switches/settings this all starts to seem to work just enough.

For reasons of silly corporate oversight/IP ownership, I cannot submit a PR myself on this, merely suggest what one may look like:

  <!-- https://github.com/CZEMacLeod/MSBuild.SDK.SystemWeb/blob/main/src/MSBuild.SDK.SystemWeb/Sdk/Sdk.targets#L18 --> 
  <PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">15.0</VisualStudioVersion>
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
    ++<VSToolsPath Condition="'$(VSToolsPathOverride)' != ''">$(VSToolsPathOverride)</VSToolsPath>++
  </PropertyGroup>

PS: would (anonymized) samples of full command lines from build, to test, to (local-folder) publish be something you might want to have/document? We have been using your nuget to great success, figuring out how to mix-match the correct MSBuild-old vs dotnet CLI-new might be quite the challenge to those unfamiliar.