Mocking components in render tree

[egil]

Hard to arrange tests
The issue #52 and #38 is an example of a test that is hard to "arrange" because a sub-component of the component under test, employs a lot of JSInterop to do its work. It could also be a 3rd party component that is used in the component under test, that has a dependency on a service, that the test would have to provide a mock of to get a test to work as expected.

Describe the solution you'd like
It would be nice to be able to mock out the sub-component that has external dependencies that is not important to the test. That would make the test much easier to arrange, being able to mock or replace a sub-component in a render tree.

It is not clear if it will be possible to mock or replace a component. A few problems I see:

1. Components are normally regular (partial) classes. Those are not easy to mock by tools such as Moq.
2. To properly mock a component, it would have to be replaced/mocked before the component is instantiated by the Renderer, through a RenderTreeBuilder.OpenComponent(). It is possible that the same trick we have discussed in Enable shallow rendering mode #17 could be repurposed, iff it is possible to create a mocked instance of the component.

Additional context
This could be related to #17.

[egil]

Based on experience from #17, it seems clear that to enable mocking/faking of components, we need to hook into the render pipeline and have a custom RenderTreeBuilder, that when its OpenComponent method is called, does something different.

We can actually replace the component with something completely different, e.g. a dedicated FakeComponent, which will receive any parameters passed to it through the SetParametersAsync method on it. That will allow us to create a component that can capture all parameters passed to the original component, and allow the test user to verify the right parameters are passed, and to even invoke EventCallback or modify the parameters.

The challenge, as noted in #17, seems to be that the parts of the rendering pipeline in Blazor is either sealed or internal, requiring us to copy a lot of source code files from the aspnetcore repo to modify and get the functionality we need.