Put package assets in TFM-specific folder

[wtgodbe]

Fixes #58990
Related: NuGet/Home#6932

When a package has a build or buildmultitargeting folder without a TFM subfolder, NuGet considers it to be compatible with any TFM. This is causing builds that should be failing with restore errors, to instead later hit a less helpful runtime error.

[wtgodbe]

Test build to get packages: https://dev.azure.com/dnceng/internal/_build/results?buildId=2582989&view=results

[adityamandaleeka]

Thanks for reporting this @loganmj and thanks @BrennanConroy and @wtgodbe for the quick investigation/fix!

[captainsafia]

Does ApiDescription.Server need a similar treatment?

[wtgodbe]

Does ApiDescription.Server need a similar treatment?

It does, nice catch. Plus I need to fix up Microsoft.AspNetCore.Identity.UI. Will do that today

[wtgodbe]

Actually, not sure if we can fix APIDescription.Server since it targets netcoreapp2.1, $(DefaultNetCoreTargetFramework), and $(DefaultNetFxTargetFramework), and the files in build/buildMultiTargeting are meant to be used on any of those. @ericstj how has dotnet/runtime solved similar problems (packages with non-TFM'd build folders are considered compatible with any TFM by nuget)

[ericstj]

We make sure to use TFMs with all assets, including build, buildTransitive.

I don't think an of our packages use buildMultiTargeting -- I can see why you can't use a framework folder there since it's part of the outer build. I think in that case you'd want to make sure your targets raised the appropriate Diagnostics when used in an unsupported project type.

[dotnet-policy-service]

Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime.
To make sure no conflicting changes have occurred, please rerun validation before merging. You can do this by leaving an /azp run comment here (requires commit rights), or by simply closing and reopening.