[Blazor] Improving ASP.NET Core integration

There are certain design choices in components that Blazor ships out of the box that make it hard to write applications that can work seamlessly on SSR scenarios and on interactive modes. This causes friction as there are many cases where the behavior is different on SSR and on Interactive sessions and developers have to account for both cases. Below is a non-exhaustive list of improvements that we can do to improve some of these experiences:
* Routing:
* There are two routers, one on the server (ASP.NET Core) and one on the client. We've merged the two implementations for the most part, but there are details that still cause confusion.
* The need to declare additional assemblies in two locations: We should make the endpoint in ASP.NET Core pass along the configured assemblies to the client project via persisted state or some other mechanism.
* Differences in handling `NotFound`: On SSR scenarios this is represented by an endpoint, on the interactive router with a `RenderFragment`. We should extend the router to take in a `NotFoundPage` parameter that can be used during SSR and Interactive rendering to display not found content.
* Lack of `NavigationManager.NotFound()` or equivalent API for triggering `NotFound` on Blazor applications. This would trigger a 404 response on SSR scenarios that would render the `NotFound` page/component and on InteractiveScenarios it would signal any registered callback (the router) the equivalent situation (which would trigger the render).
* Similar deal for triggering errors through an `Error` page.
* Authentication:
* In ASP.NET Core you can use `Challenge` to trigger/start the authentication process. There is no Blazor equivalent for it, so users end up having to manually redirect users on interactive sessions.
* We should extend `AuthenticationStateProvider` or similar APIs to support this type of scenario. On interactive sessions, a `Challenge` for a scheme will always result in a redirect (maybe challenge is not the right way to call this, and we should be using `RedirectToLogin` or some other verb. For server scenarios the information about the configured schemes is already available. For `WebAssembly` scenarios, information about the redirect URL can be provided via some mechanism like PersistedState. For schemes that need to generate additional information (like nonces, etc.) they'll be extended to add at least a new endpoint (maybe two) to handle the bootstrapping of the authentication process so that interactive clients (like webassembly) can redirect to a well-known URL to start the process.
* Lazy loading:
* With prerendering, it can happen that we prerender a path that requires lazy loaded assemblies to render. The current APIs don't offer a way to make sure those assemblies are loaded before the page tries to render, which results in failures when the app goes interactive. We need:
* A `LazyAssemblyLoader` implementation for prerendering (if you try to do this on any current .NET version it will fail).
* For a given page, a list of all the dependent assemblies that are lazy loaded.
* The ability to determine if they need to be immediately loaded for the page to render (for example, if the page references a type `B` that lives on a lazy loaded assembly on its `type definition` (`class A { public B BProp { get; set; } })` or if it can be delayed (because B is only used inside a method body).
* A way to tell the runtime to load those assemblies when booting webassembly as we know they'll be needed immediately.
* Built-in components:
* In general, we need to look at every component that we ship and ensure there's a way for them to work on each render mode in a reasonable way across render modes.
* QuickGrid.
* NavLink.
* EditForm.
* Section(s)
* Cascading parameters.