feat: Navigation will set parameters

[linkdotnet]

This closes #1580

The basic idea here is to have a router that takes care of everything. There are a few open points. I will mark them here. We can discuss this next Friday, I just had some time to do the feature today and wanted to finish it as much as possible.

[linkdotnet]

Here another "TODO"

[linkdotnet]

Just some paper-trail for our future selfs:
To make that work with bids of ASP itself,we need:

• RouteTable - that does all the nice URL segment parsing for us
• That depends on TreeRouter, which is internal for the Blazor case (see: #ifdef !COMPONENTS).
• That objects has then again a dependency that is internal for us as well: UrlMatchingTree

Assumption here is that we don't need the TreeRouter in the first place and can solely rely on RouteTable.Route method or even alternatively the internal static ProcessParameters method.

RouteTable.Route takes the TreeRouter unfortunately - so we are stuck to the limbo described above. The static version already wants a RouteData object - so the "parsed" version where the segments are already parsed to a IReadOnlyDictionar<string, object> (aka the heavy lifting!).

While properly all of that (at least three reflection invocations plus some more setup to create RouteView, HttpContext*, ...) works, I am not sure if writing the code itself (aka this PR) is so much worse.

^* The RouteContext that is used by the TreeRouter inside Route does want a HttpContext. I am not sure if I am missing something - but why does it want this in the first place? It is not even used inside that object - and gets just gets it passed in from somewhere. So we also might have to setup a HttpContext here (at least so that it doesn't throw the ArgumentNotNullException in its ctor).

CC: @egil
Not sure if I missed something here or went offtrack.

[linkdotnet]

@egil I rebased all the work on v2. Will make some other small changes to make it "ready"

[linkdotnet]

Okay done :D - now the implementation is using our renderers SetDirectParametersAsync.

That was a shortcoming that was easy to overcome with v2.

In any case many points are up to discussion. So we are not bored next Friday.