Should platform package pruning data represent GA of a framework or the serviced version?

[ericstj]

This relates to NuGet/Home#13634

We have two options:

1. Represent the GA version of the framework in this data, eg: 10.0.0, 8.0.0, etc.
2. Represent the latest patched version of the framework in this data, eg: 10.0.1, 8.0.10

Today we update our conflict resolution data (PackageOverrides.txt, PlatformManifest.xml) in servicing (option 2). In the past this was intentionally pinned at GA (option 1).

The benefit of updating this data in servicing is that it means less stuff will ship in the app when the framework version will satisfy it. So even if someone brings in Microsoft.Extensions.Hosting 9.0.2 and it's closure, you can still drop all those packages when on targeting the Asp.NETCore framework 9.0.

The downside of this is that you might be missing a hotfix package that you actually want to carry app-local if you happen to be running on an older runtime.

I tend to think that our users prefer to carry less in their app, and instead count on a framework update to keep them up to date. We can always have the escape hatch of adding a direct reference. I'd like to get other's thoughts on this cc @richlander. Based on what we decide it will determine both what the shared framework providers do with conflict resolution data, and what the SDK does with the pruning data (including for down-level frameworks).

cc @dsplaisted @nkolev92 @ViktorHofer