[Feature] URL-based navigation

[BurkusCat]

Is your feature request related to a problem? Please describe.
When doing a complicated navigation, I need to build up multiple push calls and use animation parameters in a certain way to get the navigation I want. A URI based navigation option would simplify complex navigation and provide a way for the library to do more optimised/performant navigation (with less jank).

Describe the solution you'd like
New navigation service methods for navigation to URIs. I want to be able to build up a URI manually for simpler scenarios. I should be able to pass parameters. I also should be able to use a custom, static URI builder to generate more complex URIs (e.g. where I have different parameters passed to each page along the URI). The builder should be separate from the navigation methods to allow for testability.

Describe alternatives you've considered
N/A

Proposed APIs

// INavigationService
Task Navigate(string uri);

Task Navigate(Uri uri);

Task Navigate(string uri, NavigationParameters parameters);

Task Navigate(Uri uri, NavigationParameters parameters);

This needs thought about more and improved:

// BurkusMvvmUriBuilder
var uri = new BurkusMvvmUriBuilder()
    .AddSegment(nameof(PageOne))
    .AddParameters(new NavigationParameters { { "test", 2 } })
    .AddSegment(nameof(PageTwo))
    .Build()

navigationService.Navigate(uri);

Additional context
N/A

[BurkusCat]

Some implementation ideas:

• Split the URL into a series of steps
• Is it an absolute URL?
  • Do a reset and push navigation page first?
• Push pages and trigger their OnNavigatedToEvents in sequence
  • Presumably OnNavigatedFrom shouldn't be triggered for most pages?
• Trigger OnNavigatedFrom for the page before the navigation begins (probably the first thing that should be done)
• Parameters should be taken into account at each segment for tab switching, modals and animations

[BurkusCat]

In the proposal, I suggested Task Navigate(Uri uri); as an option. In practice, I think passing a real Uri object to this method is unlikely to be more useful than a string given the URI syntax for this framework isn't really a proper URL with a domain etc. It probably makes sense to not have this method, and just have the string method.

[BurkusCat]

The merged PR adds this feature but I expect the behaviour to need to change over time. I expect that the jankiness of the visuals could be improved, that when parameters trigger could be improved etc.