Support multi-targeting for Roslyn components

[eerhardt]

Opening an issue here to add support for dotnet/sdk#20355 in the ResolveNuGetPackageAssets Task. We need to update the NuGet MSBuild logic with support for multi-targeted Roslyn components. That way developers using non-SDK .NET projects will get the same Analyzers selected as SDK projects.

Any non-SDK style projects that are referencing NuGet packages with multi-targeted Source Generators (ex. System.Text.Json and Microsoft.Extensions.Logging.Abstractions) are not getting the best possible Source Generator loaded. This results in slower builds and IDE interactions because the source generators targeting older Roslyn versions don't have the latest incremental logic in them. They need newer Roslyn versions to fix the performance bugs.

Those NuGet packages have fallback logic when SupportsRoslynComponentVersioning is not true to just pick the oldest supported version. This allows the NuGet package to work with older tools that don't support multi-targeting Roslyn. But when SupportsRoslynComponentVersioning is set to true, the tooling that picks the analyzer assets from the NuGet package will pick the correct Source Generator/Analyzer based on the Roslyn version targeted and the current $(CompilerApiVersion).

We should re-implement the logic that is used in SDK-style projects (dotnet/sdk#20793) in the ResolveNuGetPackageAssets Task.

See also dotnet/roslyn#63522 (comment)

cc @ericstj

[baronfel]

This also seems to impact SDK-style projects when an analyzer package includes both an 'unversioned' and a 'versioned' Roslyn analyzer reference - it would be great if ResolveNuGetPackageAssets could protect users from known-impacted package layouts like this. See dotnet/sdk#41352 for reference.