Enforce circuit termination on unhandled exception

[SteveSandersonMS]

From #11791

Currently we have many code paths that catch exceptions and then pass them to Renderer.HandleException but otherwise swallow the exception. From there, Renderer.HandleException logs the exception on the server, and sends a (redacted) exception message to the client, which then terminates the connection.

It's not good enough to trust that the client will actually terminate the connection. It might not do, and then the circuit will continue running but in an unknown state.

When fixing this, add tests to show we now enforce server-side circuit termination (but the application process itself continues to run and accept new circuits) in:

• Exceptions in component instantiation (e.g., in component constructor or IComponent.Configure)
• Exceptions from IComponent.SetParametersAsync
• Exceptions from event handlers
  • TBD: We might choose that an unhandled exception from an event handler shouldn't terminate the circuit, but rather just goes back to the client as a JS interop exception. That's kind of the behavior today, except we also have a bug (Renderer.DispatchEventAsync throws null reference exception if event handler throws synchronously #11847).
    • However, it's unclear to me why we'd be loose about event handler exceptions but strict about lifecycle-method exceptions (e.g., in OnInitAsync). We have to be strict about lifecycle-method exceptions because it doesn't make sense to continue using the app when parts of the UI are dead. We would need some kind of "dead component" UI to appear instead of the failed component.
• Exceptions from OnAfterRenderAsync (called by Renderer.NotifyRenderCompleted)
• Exceptions that happen during a component's Dispose.
  • But be sure that, if this happens while a circuit itself is being disposed, we still go on to dispose the other components in the circuit and complete the rest of the circuit disposal process (including disposing the DI scope).