[Feature]: Allow Maintainers to specify additionally supported target frameworks

NuGet Product(s) Involved

NuGet.exe, dotnet.exe

The Elevator Pitch

The list of supported frameworks becomes increasingly important, and many packages still trying to support old as well as new targets, causing the list of supported frameworks is increasingly confusing and allowing maintainers to help clear up this confusion would be much appreciated.
Many packages support "old" frameworks like .NET Framework 4.x, .NET Standard 2.0, and shipping extra features with newer frameworks (.NET Core 3.1, .NET 5, .NET 6), the problem becomes that there is no clear way to indicate which frameworks are actually supported, and to what extent.
For example, if a package ships 2 versions, one for .NET Standard 2.0 and one for .NET 5, a .NET 6 user will fall back to the .NET 5 implementation, but this isn't immediately clear, all they will generally see is either "my target is not supported" or with the new display on NuGet.org that it's supported via some other target, but they have no way of knowing whether the package is up-to-date with the latest features (ie Span) or whether they just support .NET Standard 2.0, and support .NET 6 just as much as .NET Framework 4.8.
Package maintainers can't do anything to clear up this confusing if they don't want to duplicate their assemblies many times for all actually supported frameworks. (For example, many packages don't need to do anything to support .NET 6 to the fullest, as none of the new features are of interest to them directly)

I want to suggest a property like <PackageAdditionalTargetFrameworks>...</PackageAdditionalTargetFrameworks> that is validated on package (if .NET Framework 3.5 is specified there, but only .NET 5 is actually implemented in TargetFrameworks, an error is thrown given there is no way this is possible) and simply specifies that a target framework is officially supported, and not just incidentally. This information can then be used by UI tools like the website or IDE package managers to indicate that this package is explicitly supported, helping the user make an informed choice of which package to choose.

This property has no effect other than exposing some information to UI, the validation is really optional but nice to have.

Additional Context and Details

I'm a maintainer at Silk.NET and we have been struggling with this, I think our packages serve as a good example why users may be confused when trying to understand to what degree they are supported. For example, our Silk.NET.Vulkan package on NuGet.org.