[NETSDKE2E]Workloads which are installed in CLI are not displayed after upgrading from VS17.4 to VS 17.5

[vdanche]

1. Install VS 17.4(Pipelines - Run rel.d17.4-33401.170 (visualstudio.com)) which contains Feb update

2. Once VS 17.4 installation is done. Install workloads in CLI. e.g
   dotnet workload install wasm-tools --skip-manifest-update
   Run "dotnet workload list" to check the installed workload.

3. Install VS 17.5 GA build(Pipelines - Run rel.d17.5-33401.271 (visualstudio.com)) to upgrade

4. After upgrade, "dotnet workload list" to check the installed workloads in VS 17.4

Expected Result:
Steps 2(on VS 17.4)

The installed workloads of steps2 can be displayed after upgrade on 17.5.

Actual Result:
The installed workloads of steps2 are missing on VS 17.5.

dotnet --info

Note:
if install SDK separately, the scenario is different as 7.0.103 and 7.0.200 can co-exist.

1. Install 7.0.103, install workload in CLI: dotnet workload install wasm-tools --skip-manifest-update
2. Install 7.0.200, define SDK version as "7.0.103" via globaljson file and then dotnet worklist list to check installed workload.
   The workload can be displayed.
   
   if not define SDK version(7.0.200 by default), no any workloads which shoud be expected.
   

[marcpopMSFT]

There are a couple of items in dotnet/sdk#30008 that cover scenarios similar to this but not this exact thing. What's happening here is that the CLI install of the workload is getting overwritten by VS but since the packs weren't selected in VS, they are no longer valid. That's kind of how it's designed but we can discuss if there is anything we can do here to imprvoe it. CC @dsplaisted @joeloff

[marcpopMSFT]

Old issue triage: VS will overwrite the manifests but the first run after an upgrade should try to update your workloads for you. That was the only solution we had.