Add Application.TryGetFeature, re-add new feature - IActivatableLifetime

[maxkatz6]

What does the pull request do?

Partially redoing #14106 in a form of different API. While keeping ABI compatibility (old interface is a no-op now though).
And restoring #14492 changes.

Now instead of using optional Application.Lifetime, this feature can be accessed from Application.TryGetFeature.

Obsoletions / Deprecations

Old interface is obsolete and marked as error, with hints on new API.

[avaloniaui-bot]

You can test this PR using the following package version. 11.1.999-cibuild0044705-beta. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[avaloniaui-bot]

You can test this PR using the following package version. 11.1.999-cibuild0044709-beta. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[kekekeks]

Quick question: how does "activation" works with Android when media gallery or camera activity get requested? It would make our activity to be "deactivated", IIRC.

[maxkatz6]

It would make our activity to be "deactivated", IIRC.

Correct. But I would say it's an expected behavior, as activity is not anymore in the user view. As per Android documentation, OnStop - "Activity is no longer visible", and OnStart - "Activity is active again". Same logic can be applied to the Avalonia events.
And developer would react in the same way to these event - pause any background work, like media playback or, possibly, animations running.

[avaloniaui-bot]

You can test this PR using the following package version. 11.1.999-cibuild0044773-beta. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[kekekeks]

But I would say it's an expected behavior

It won't be consistent with other platforms where deactivation is an app-wide event.

[avaloniaui-bot]

You can test this PR using the following package version. 11.1.999-cibuild0044932-beta. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[maxkatz6]

It won't be consistent with other platforms where deactivation is an app-wide event.

@kekekeks the only other option would be to not implement this API on Android at all, which is still valid. The problem is, we don't have a Scene/Window API for mobile, to handle it on per-activity level as well.

Right now, in this PR, we assume, that root main activity represents the app. That's where these events are raised. Which isn't exactly correct for these situations when user might decide to manually create activities and completely skip conventional Avalonia initialization there. That's where it is different from other platforms, where it is in fact global. But I still don't see issue with child activities (such as file dialogs), as no events are raised from them - only main activity is hidden or shown as visibility to user is changed, and that's excepted imo.

[maxkatz6]

Merging after @kekekeks verbal approval