Workloads commands (and other implicit msbuild usage) should not share msbuild warnings by default (only in /bl or diag mode)

[JanKrivanek]

Context

This is followup on dotnet/msbuild#10468
Adding /p:NoWarn=MSB3982 to dotnet workload restore is ignored - it's not passed through to msbuild.
Ideally the parameter would be flagged as not supported, or otherwise passed through to msbuild

[nagilson]

Adding to team triage to decide priority.

[marcpopMSFT]

I changed the title as there are a set of .net cli commands that we do not want the customer to have visibility into how it's implemented and there's no reason to expose the MSBuild usage. Potentially, we might even want to suppress env processing in MSBuild but perhaps that's a step too far.

Either way, we'd want a way to get this back in case we need it for diagnostics in the future. moving to net10.

[nagilson]

Baronfel: In the simplest form, it might be as easy as setting a few more properties here where we call MSBuild on the projects:

sdk/src/Cli/dotnet/commands/dotnet-workload/restore/WorkloadRestoreCommand.cs

Lines 77 to 80 in 8634876

	var globalProperties = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase)
	{
	{"SkipResolvePackageAssets", "true"}
	};

WorkloadRestoreCommand.cs
dotnet/sdk

e.g. TreatWarningsAsErrors, "false"