Added new result awaiting and setting ViewModel navigation

[entdark]

✨ What kind of change does this PR introduce? (Bug fix, feature, docs update...)

Adds new IMvxResultAwaitingViewModel<TResult> and IMvxResultSettingViewModel<TResult> interfaces and corresponding abstract classes to create a result navigation contract between the awaiting and setting the result ViewModels. Under the hood it uses a new IMvxResultViewModelManager that registers, unregisters and sets the result to the registered result awaiting ViewModels.

It's better to use predefined abstract classes MvxResultAwaitingViewModel<TResult>, MvxMultiResultAwaitingViewModel<TResult1, TResult2>, MvxResultSettingViewModel<TResult>, MvxNavigationResultAwaitingViewModel<TResult>, MvxNavigationResultSettingViewModel<TResult>, and their overloads with parameters. Because when implementing IMvxResultAwaitingViewModel<TResult> and IMvxResultSettingViewModel<TResult> manually it requires implementing ViewModels registering, saving, restoring, unregistering, and setting the result manually as well.

⤵️ What is the current behavior?

No navigation with awaiting the result.

🆕 What is the new behavior (if this is a feature change)?

Navigation with awaiting the result that also survives Android restoration.

💥 Does this PR introduce a breaking change?

No.

🐛 Recommendations for testing

0. Prepare an Android 13+ device or emulator since we need runtime Notification permission.
1. Deploy the Playground.Droid app.
2. Start it without debugging since the app will be shut down later.
3. Click "SHOW CHILD" button - it will show a child Fragment on bottom
4. Minimize the app (not close) by clicking Home or Overview.
5. Go to the Playground.Droid app system settings.
6. Make sure Notifications permission is granted.
7. Disable Notifications permission.
8. Go back to the app.
9. The app will be restored with the child Fragment on bottom.
10. Click "CLOSE" in the child Fragment.
11. Check the logcat (via your preferred IDE): it should display

Info (26885) / RootViewModel: [Information] Result Playground.Core.Models.SampleModel from Playground.Core.ViewModels.ChildViewModel

12. We received the awaited result after the full app restoration (with shutting down).

You can test this with any dangerous permissions.
Developer option "Don't keep activities" works differently - it does not shut down the app. Though the feature also works in this case.

For other platforms it just works without restoration issues.

📝 Links to relevant issues/docs

PRs: #4312 #4652
Issues: #3342 #3980 #4230 #4262 #4553 #4651

🤔 Checklist before submitting

• All projects build
• Follows style guide lines (code style guide)
• Relevant documentation was updated (docs style guide)
• Rebased onto current develop

🧠 Extra

I am open for discussing changes for the implementation.
Here are some ideas:

• move 3 new navigation extensions to the navigation service directly
• handle default implementations differently through default interface declaration
• rename those long interface and class names to shorter ones

[Cheesebaron]

Thanks will have a look at reviewing this one soon.

[picosmos]

@Cheesebaron Can you say when you think you'll be looking at this?

We are currently migrating a project and are considering whether to use the code from this PR or our own implementation from another project. (it's a similar strategy, but we would prefer to use framework features if possible. But unfortunately we can't wait that long anymore.)
Thank you for your great work :)

[entdark]

@picosmos
I think if you hurry then it's better to go with your own.
I am not pleased with the solution in a few places and also probably there will be review fixes.

[Cheesebaron]

@Cheesebaron Can you say when you think you'll be looking at this?

We are currently migrating a project and are considering whether to use the code from this PR or our own implementation from another project. (it's a similar strategy, but we would prefer to use framework features if possible. But unfortunately we can't wait that long anymore.) Thank you for your great work :)

Sorry, I won't rush a review just because someone needs it. This looks something that would be easy to add to your own presenter override or use an alternative. Even if it gets reviewed and merged in, there is no guarantee there is a release with this in soon either.

I hope you understand :)

[picosmos]

@Cheesebaron Can you say when you think you'll be looking at this?
We are currently migrating a project and are considering whether to use the code from this PR or our own implementation from another project. (it's a similar strategy, but we would prefer to use framework features if possible. But unfortunately we can't wait that long anymore.) Thank you for your great work :)

Sorry, I won't rush a review just because someone needs it. This looks something that would be easy to add to your own presenter override or use an alternative. Even if it gets reviewed and merged in, there is no guarantee there is a release with this in soon either.

I hope you understand :)

Sure, that's the right way to do. I think we use our own implementation.