Improve targeting pack acquisition

[richlander]

The pattern we use for acquiring targeting packs no longer makes sense. We chose the pattern because we were still creating new .NET Framework versions every year or two and new targeting packs with them. We needed a versioning scheme where the target framework archives we publish didn't change (for compat). We designed a scheme for that, which can be seen in the implementation. In retrospect, we could have chosen a simpler scheme, but that's now history.

dotnet-framework-docker/src/sdk/4.8.1/windowsservercore-ltsc2022/Dockerfile

Lines 71 to 83 in 58a18cf

	# Install Targeting Packs
	RUN powershell " `
	$ErrorActionPreference = 'Stop'; `
	$ProgressPreference = 'SilentlyContinue'; `
	@('4.0', '4.5.2', '4.6.2', '4.7.2', '4.8', '4.8.1') `
	| %{ `
	Invoke-WebRequest `
	-UseBasicParsing `
	-Uri https://dotnetbinaries.blob.core.windows.net/referenceassemblies/v${_}.zip `
	-OutFile referenceassemblies.zip; `
	Expand-Archive referenceassemblies.zip -DestinationPath \"${Env:ProgramFiles(x86)}\Reference Assemblies\Microsoft\Framework\.NETFramework\"; `
	Remove-Item -Force referenceassemblies.zip; `
	}"

Let's assume the following:

• No new .NET Framework versions and therefore no new target frameworks
• Content integrity is a key tenet of delivering high-quality software
• The pattern above is cryptic and not all that attractive.

We should then:

• Make a new target framework archive, including all the target frameworks. We can still version it in some way (like timestamp it).
• Create a content hash for it validate that in the Dockerfile (like we do in other Dockerfiles).
• Acquire this single archive in a simpler more standard way (no funky looping).

[lbussell]

Completed with #1224 and #1234. While we didn't eliminate the loop, we now consume the targeting packs directly from the NuGet packages which means we don't have a dependency on any hand-crafted archive of targeting packs.