[Blazor] Getting rid of Blazor.boot.json and using a different strategy to flow the environment.

[javiercn]

Blazor webassembly environment can be configured through a response header on blazor.boot.json or directly within the call to Blazor.start in code. The environment typically flows from the ASPNETCORE_ENVIRONMENT on the server.

This approach is problematic because two reasons:

• We can't fingerprint blazor.boot.json the same way we do for other files (we can't leverage the importmap), and we always need to request it to the server bypassing the cache to ensure it's up to date (because it's not fingerprinted).
• Setting a header for blazor.boot.json is not always possible in standalone scenarios (like when hosting on Github pages), it's also environment dependent and hard to do.

We want blazor.boot.json to become boot.js as when it's an ES6 module, it can be easily fingerprinted by an importmap on hosted scenarios as well as on standalone scenarios by rewriting index.html and using a servicer-worker.

We can write the environment directly inside boot.js and allow the app to override it in a couple of ways:

• We can use a comment in the document as we emit the initial response.
• We can use a meta tag in the head.

For standalone scenarios, we can read the environment from launchSettings.json during build and place it on boot.js and we can read/take the environment from an MSBuild property at publish time.

With this, we bypass issues like #25152 and we make it possible for the entire resource load chain to be fingerprinted, avoid having to make uncached requests, and have a simpler deployment independent mechanism for flowing the environment.