Clean up containers packaging, leaning into NuGet's expected patterns

[baronfel]

NuGet expects folks that want to customize output paths (i.e. non-library packages) to use the TargetsForTfmSpecificContentInPackage extensibility point to create TfmSpecificPackageFile Items with PackagePath metadata.

Instead of our old custom orchestration, we lean into this. I also cleaned up how we determine the dependencies to package for the containerize.dll binary.

This can be tested very easily by running dotnet pack -bl on the packaging.csproj project itself (or dotnet build, because we have GeneratePackageOnBuild set for this project).

[Copilot]

Pull Request Overview

This PR cleans up the packaging logic by leveraging NuGet’s expected patterns for custom output paths and streamlines dependency determination for the containerize binary. Key changes include:

• Adding the TargetsForTfmSpecificContentInPackage property to drive packaging for TFM-specific content.
• Updating ProjectReference target definitions to use the new SdkTargetFramework and introducing explicit OutputItemType attributes.
• Refactoring packaging targets (PreparePackageReleaseNotesFromFile and AddItemsForPackaging) to generate package files using TfmSpecificPackageFile items.

Comments suppressed due to low confidence (3)

src/Containers/packaging/package.csproj:29

• Ensure that replacing $(TargetFramework) with $(SdkTargetFramework) is intentional and that all dependent tasks and project references are updated accordingly to avoid framework mismatches.

                          SetTargetFramework="TargetFramework=$(SdkTargetFramework)"

src/Containers/packaging/package.csproj:45

• [nitpick] Verify that the naming 'ContainerizeBinaryOutput' for the output item type is consistent with other similar identifiers in the project to maintain clarity.

                          OutputItemType="ContainerizeBinaryOutput"