Bring back microsoft store build of mpv.net

[soredake]

Is your feature request related to a problem? Please describe.
Microsoft store version have advantages over winget/scoop/chocolatey packages:

1. Problems like this will not happen in msstore package Attempt to close running instance during Windows installer qbittorrent/qBittorrent#18582
2. You don't need to manually add mpv.net to PATH
3. You don't need to manually register Audio/Video associations.
4. No "smart screen" warning before launch
   
5. No UAC is needed to install mpv.net
   

Describe the solution you'd like
Bring back mpv.net to microsoft store, maybe this project will help https://github.com/SilverEzhik/mpv-msix

Describe alternatives you've considered
Using mpv-msix

Additional context
Add any other context or screenshots about the feature request here.

[candrapersada]

Even though mpv.net returns to the Microsoft Store, you still have to install or use the .NET Desktop Runtime

[soredake]

@candrapersada .net runtime can be bundled into exe like in this software https://www.nexusmods.com/batmanarkhamasylum/mods/117?tab=files (i don't care about size increase honestly)

[Witchilich]

Scoop already automatically adds it to path and winget automatically installs .NET desktop runtime dependency while installing. I prefer the winget solution, but it would be great to have it back on Microsoft Store.

[9ao9ai9ar]

As a reference, both Krita and MKVToolNix release their programs onto the Microsoft Store for a fee to fund their projects while also providing traditional installation means for free. A Microsoft Store version of mpv.net would not be without disadvantages however:

1. The Microsoft Store is neither available nor officially supported on Windows Server and Windows IoT/Enterprise editions (so is winget at the moment).
2. Because the installation directory changes with each update, it is a hassle to add firewall rules to store apps (might or might not be relevant to mpv.net).
3. The Microsoft Store does not provide APIs to interface with scripts, so automation is harder (there is Appx-Backup but that looks like a lot of work).
4. You have to follow the Microsoft Store policies, for better or worse.

I've also looked into scoop/winget/chocolatey, and they each have their own strengths and weaknesses. I try to summarize them succinctly:

1. Scoop is PowerShell friendly and is especially suited for installing CLI applications, but there is zero automated testing and malware scanning done on its apps, and scoop virustotal was unusable for me even with an API key for some reason.
2. WinGet benefits from being an official Microsoft product, but as mentioned earlier it is only available on consumer versions of Windows, and feature-wise is not as good as scoop.
3. Chocolatey is the only one that actually does dependency management so is often slower, but it feels old-school.

My personal preference would be MSI/MSIX, followed by EXE then WinGet, the two current solutions.