Build blazor.*.js in CI; don't commit the artifacts

[SteveSandersonMS]

At some point in the recent past, we started including blazor.*.js in source control. This was intended as a way of avoiding the Node dependency in some CI cases. However, it turns out that:

• This is very damaging to productivity, as it forces us to shepherd our PRs through CI in series, not in parallel. Every commit that affects the blazor.*.js artifacts causes a merge conflict for every other such commit, even if they were only touching completely unrelated files. Some work items have been queued up for days due to this.
• It's super annoying that sometimes you wait ages for a CI build result, and it fails claiming your output was out of date, even though in some cases that doesn't appear to be true. We haven't tracked down the exact conditions under which this occurs, though it might be something like when SignalR makes changes that overlap with the PR's lifetime.
• It turns out to be completely unnecessary anyway. We've consulted with the build team (Doug/John, plus Chris regarding source build) and everyone agrees it's actually completely fine to use Node during CI builds, and it's already installed in all our environments except CentOS (where it can be installed via yum).

The build team has agreed to support us with figuring out how to make this change, though @dougbu is asking that someone from the Blazor crew actually do it.

[BrennanConroy]

completely fine to use Node during CI builds

SignalR has been doing this since the beginning. If you need any help or guidance you can ask us or take a look at our npm builds. https://github.com/aspnet/AspNetCore/tree/master/src/SignalR/clients/ts

[JunTaoLuo]

This has been completed in #12145