Bring back UWP support

Is your feature request related to a problem? Please describe.
Stride 4.1 updated to .NET 6, and in the process dropped UWP support because it doesn't officially support .NET 5+. Without UWP support, there is no easy way to publish natively to Xbox or Hololens (or Team, perhaps for technical visualizations?).

Describe the solution you'd like
Although UWP does not officially support .NET 6, it's possible and actually quite easy to make a .NET 6 UWP app. It can even be published to the Microsoft Store without issues, though of course you don't have to. Gustave Monce put together a proof-of-concept for a UWP XAML app targeting .NET 6 here: gus33000/CsUWP. Note that Gus used a modified version of C#/WinRT to generate a projection for Windows.UI.Xaml, but since Stride 4.0 supported CoreApplication directly, we don't need to worry about that or anything else involving XAML.

As is, Stride.Core can be referenced from .NET 6 UWP, but because the STRIDE_PLATFORM_UWP directive isn't defined for the standard net6.0 target in Stride 4.1, it incorrectly attempts to use the System.IO APIs to access the current working directory. This can be solved in a few ways:

1. Check for UWP at compile time by explicitly adding net6.0-windows10.22000 as a target framework. Games built with this target will run only on Windows 10 and up, and as such can be UWP apps without conflicts. The net6.0 target will cover any Windows 7+ system. The benefit of this is that the 4.1 codebase would require minimal changes, as the STRIDE_PLATFORM_UWP can be set whenever the target framework OS is windows10. The downside is that the UWP version would erroneously be referenced if someone wanted to embed a Stride game in a WPF/WinForms/etc. project that also targets net6.0-windows10.
2. Check for UWP at run time by calling the GetTokenInformation Win32 API with the TokenIsAppContainer class. This method can determine if the current process is running in an app container, which strictly speaking isn't limited to UWP apps, but should be effective and is officially supported. This has the benefit of not fudging the target frameworks, but since it's a run time check, the WinRT libraries have to be referenced even if the target OS won't use it. This shouldn't cause issues with the game itself, but it does mean adding a library that might never be used on certain OSes.

Describe alternatives you've considered
As far as I know, without Stride multitargeting both net6.0 and uap10, there are no other options.

Additional context
I'll be working on a proof-of-concept at yoshiask/Stride41Uwp, that runs the "Space Escape" sample game in a UWP app targeting .NET 6. (It's private at the moment because I haven't made many changes to Gus's CsUWP repo.)

Start with Stride.Core and trace how the STRIDE_PLATFORM_UWP directive and net6.0 target handle current-directory access. Compare the proposed compile-time and run-time UWP detection approaches, then use the Space Escape proof of concept to verify that a .NET 6 UWP app can reference Stride and publish for the intended platforms.