Link more assemblies by generating XML config files

[SteveSandersonMS]

This is a possible implementation for #17022, but I don't actually want us to do this. I'm going to mark the PR as closed straight away. The only reason I'm submitting this PR is for future reference in case either dotnet/linker#854 gets rejected, or we come up with some other reason to want to generate linker XML config files during the build.

This PR includes a new MSBuild tasks assembly, Microsoft.AspNetCore.Components.Build that is only for internal use and would not be shipped. During the build, for each project that includes AddLinkerConfigGeneration.targets, it:

• If you pass /p:RegenerateLinkerConfig=true, emits a file called <AssemblyName>.linkerconfig.xml, containing linker rules based on ASP.NET Core / Blazor patterns, i.e.,
  • preserve all IComponent types completely, since their constructors and property-setters are used through reflection only
  • preserve all [JSinterop] methods, since they are called through reflection only
  • preserve all DI service types, since their constructors are called through reflection only
  • preserve all EventArgs subclasses, since their property setters are called through reflection only
• Otherwise,
  • Embeds <AssemblyName>.linkerconfig.xml as a resource called <AssemblyName>.xml (which is what the linker looks for), if such a file exists on disk
  • Validates that the resulting assembly contains an embedded resource called <AssemblyName>.xml and that its contents exactly match what would have been generated if you had passed /p:RegenerateLinkerConfig=true. If not, fails the build.

In other words, it's very much like our flow for generating reference assemblies, storing them in source control, and validating their up-to-dateness during build. I chose this approach (versus simply generating and embedding on every build) so that humans would manually inspect the diffs to the xml config files and reason about their correctness. This means we inherently have baselines for correct output and don't want a different set of tests for this functionality.

Why I don't like this

It's really complicated.

It means creating a new MSBuild tasks assembly on build, which comes with all the awful mess of locking files and caring about VS running MSBuild as netfx versus netcore. I hate this stuff.

We have to use Mono.Cecil to generate the configs. We can't use System.Reflection.Metadata or anything based on it, because the Mono linker only recognizes the exact method signature string format produced by Cecil.

The resulting size reductions aren't as big as with #17819.

[SteveSandersonMS]

Closing because I don't want this to happen. This PR only exists so I can search for it in the future when trying to do similar things.