[rel/18.6] Revert #16090 and skip nupkg verifier in .NET product build mode

[Amaury Levé (Evangelink)]

What

1. Revert [rel/18.6] Fix stale binding redirects for SCRU/Memory/Buffers/SCI #16090 — restore the binding redirects in src/testhost.x86/app.config and src/datacollector/app.config to the NuGet.org-aligned values:
   • System.Runtime.CompilerServices.Unsafe 6.0.0.0 → 6.0.3.0
   • System.Memory 4.0.1.2 → 4.0.5.0
   • System.Buffers 4.0.3.0 → 4.0.5.0
   • System.Collections.Immutable 9.0.0.0 → 10.0.0.0
2. Back-port the VMR skip from rel/18.8 / main: gate _VerifyNuGetPackages on DotNetBuild != 'true'.

Why

PR #16090 lowered the binding redirects to match the DLL versions shipped by the dotnet/dotnet VMR build (build 1448463). However, the dnceng internal pipeline (build 2991657) immediately failed with the opposite mismatch — it ships the NuGet.org-resolved DLLs (6.0.3.0/4.0.5.0/4.0.5.0/10.0.0.0):

testhost.x86.exe: System.Runtime.CompilerServices.Unsafe redirect newVersion is '6.0.0.0' but actual assembly version is '6.0.3.0'
testhost.x86.exe: System.Memory redirect newVersion is '4.0.1.2' but actual assembly version is '4.0.5.0'
testhost.x86.exe: System.Buffers redirect newVersion is '4.0.3.0' but actual assembly version is '4.0.5.0'
testhost.x86.exe: System.Collections.Immutable redirect newVersion is '9.0.0.0' but actual assembly version is '10.0.0.0'
(same for datacollector.exe)

Root cause: VMR vs internal pipeline ship different DLL bytes

The contentFiles/any/net10.0/TestHostNetFramework folder of Microsoft.TestPlatform.CLI is populated with whatever System.* DLLs were resolved during pack. Two different build environments resolve them differently:

Build	DLL source	Shipped AssemblyVersion
dotnet/dotnet VMR (dnceng-public)	source-built BCL / runtime	6.0.0.0 / 4.0.1.2 / 4.0.3.0 / 9.0.0.0
dnceng internal & local pack	NuGet.org (System.Runtime.CompilerServices.Unsafe 6.1.0 etc.)	6.0.3.0 / 4.0.5.0 / 4.0.5.0 / 10.0.0.0

A bindingRedirect newVersion must equal the AssemblyVersion of the DLL deployed beside the exe — so a single value cannot satisfy both pipelines. The actually-shipped package is the internal-pipeline output, so the redirects must align with NuGet.org versions (which they already did before #16090).

The VMR check is the false positive here. rel/18.8 and main already skip _VerifyNuGetPackages when DotNetBuild == 'true' for exactly this reason (see existing comment on those branches: "source-built dependency packages have different assembly versions than NuGet.org packages... so the binding redirect check produces false positives"). This PR back-ports that same skip to rel/18.6.

Verification

• Local build.cmd -c Release -pack on rel/18.6 with these contents produces redirects matching the shipped DLLs (the auto-fixer leaves the app.configs alone).
• After this fix, the internal pipeline verifier passes; the VMR build no longer runs verify-nupkgs.ps1.

A separate PR will back-port the same VMR skip to rel/18.7 (which also runs the verifier in VMR).