[build] extract .NET workloads to a temp folder

[jonathanpeppers]

Description of Change

Our build currently emits some confusing warnings such as:

Microsoft.NET.Sdk.ImportWorkloads.props(14,3): warning MSB4243: The NuGet-based SDK resolver failed to run because NuGet assemblies could not be located.
Check your installation of MSBuild or set the environment variable "MSBUILD_NUGET_PATH" to the folder that contains the required NuGet assemblies.
Could not find file 'D:\repos\dotnet\maui\bin\dotnet\sdk-manifests\6.0.100\microsoft.build.notargets\WorkloadManifest.json'.

Only the very last line is actually relevant:

Could not find file 'D:\repos\dotnet\maui\bin\dotnet\sdk-manifests\6.0.100\microsoft.build.notargets\WorkloadManifest.json'.

This is because we are extracting the workload .nupkg files directly
into bin/dotnet/sdk-manifests/6.0.100 with the $NUGET_PACKAGES
environment variable. Because we are using NuGet to do this, we hit
some weird problems like extra directories getting created by NuGet:

• microsoft.build.notargets
• microsoft.netcore.platforms
• netstandard.library

A better fix for this problem is to extract the files into:

.\bin\temp\

...and then we move the WorkloadManifest.* files to the locations we
need. Any extra files can just be left in temp, so they will not
cause problems in future builds.

To clean things up more, I removed the .manifest-6.0.100 string from
the directory names, so they match what is in dotnet/installer.

I also moved a few MSBuild properties to Directory.Build.props so
they could be used throughout the entire repo down the road. This will
assist in making .NET MAUI a workload.

PR Checklist

• Targets the correct branch
• Tests are passing (or failures are unrelated)
• Targets a single property for a single control (or intertwined few properties)
• Adds the property to the appropriate interface
• Avoids any changes not essential to the handler property
• Adds the mapping to the PropertyMapper in the handler
• Adds the mapping method to the Android, iOS, and Standard aspects of the handler
• Implements the actual property updates (usually in extension methods in the Platform section of Core)
• Tags ported renderer methods with [PortHandler]
• Adds an example of the property to the sample project (MainPage)
• Adds the property to the stub class
• Implements basic property tests in DeviceTests

Does this PR touch anything that might affect accessibility?

• Does this PR introduce a new control? (If yes, add an example using SemanticProperties to the SemanticsPage)
• APIs that modify focusability?
• APIs that modify any text property on a control?
• Does this PR modify view nesting or view arrangement in anyway?
• Is there the smallest possibility that your PR will change accessibility?
• I'm not sure, please help me