Split .Components.Build into .Blazor.Build+.Components.Build

[SteveSandersonMS]

This makes the WebAssembly-specific builds steps optional. If you reference Microsoft.AspNetCore.Blazor.Build then you get the WebAssembly+RazorComponents build, whereas if you reference Microsoft.AspNetCore.Components.Build then you only get the RazorComponents part of the build.

This is in preparation for a follow-up change that will eliminate the WebAssembly build steps entirely from the Razor Components template.

[SteveSandersonMS]

@rynowak @javiercn CR notes I know this PR isn't very easy to review and be certain it's correct, since most of the changes are just things moving from one place to another. The basic concept is that almost everything from Components.Build has moved to Blazor.Build, with the only remaining piece in Components.Build being the MSBuild props that enable the new Razor compilation features (and ultimately we will aim to remove this too, but not right now).

It would be great to be able to merge this tomorrow (my time) because there's another chunky piece of work that depends on this.

[javiercn]

Does this need to be in ship or just the components part?

[SteveSandersonMS]

We're shipping all the Blazor.* packages (to NuGet) as well as the Components.* ones (some of which will be in shared framework).

[rynowak]

The only concern here that I have here is that any MSBuild we ship ultimately needs to go in some SDK or else it's very precarious. For instance if you get Components.Build through the shared framework, it won't do anything. VS if you reference it as a package it will do all of the things.

Basically, we need to do work to rationalize all of this. I created an item to track defining how the MSBuild will work for a Component Class LIbrary, and I think the other thing that's tracked is rationalizing how all of this static file stuff works.

I think this is an improvement for the time being and I'm glad to see it done 👍

[SteveSandersonMS]

Basically, we need to do work to rationalize all of this

I completely agree. My hope is that the MSBuild props set in this PR in Microsoft.AspNetCore.Components.Build can ultimately be removed altogether, and whatever design we settle on for embedded content files can become a native Razor (or Web) SDK feature. At that point, Microsoft.AspNetCore.Components.Build would become redundant we we eliminate it entirely.

The current state is just a stepping stone to the clean world of the future where these are all the defaults anyway :)

[javiercn]

I created an item to track defining how the MSBuild will work for a Component Class LIbrary

This is also a concern for RazorClassLibraries. I would hope that whatever solution we find, it can be shared across both of them.