Update Flatpak support

[R1kaB3rN]

This pull request updates the Flatpak manifest and the launcher to support running in a Flatpak environment. Flatpak clients who wish to use umu as their backend will be required to change their manifest to permit access to umu's $XDG_DATA_HOME/umu directory where the Steam Runtime platform and the launcher files will be stored/copied to.

[R1kaB3rN]

cc @GloriousEggroll

[R1kaB3rN]

This won't build since the changes are not merged in main, so will probably have to create another branch

[loathingKernel]

• If we decide to spawn SLR through flatpak-spawn can you also make the flatpak manifest simpler?
• Also we should update the the makefile to create a special umu-run for umu-launcher's Steam integration, to call the flatpak instead of .local/share/umu/umu_run.py, so we can make sure we always run the flatpak to update the user-local files on umu updates.

[loathingKernel]

Also we should update the the makefile to create a special umu-run for umu-launcher's Steam integration, to call the flatpak instead of .local/share/umu/umu_run.py, so we can make sure we always run the flatpak to update the user-local files on umu updates.

Attaching a patch for the makefile to resolve this 0001-makefile-Install-umu-run-for-umu-launcher-steam-tool.patch.txt

Patch does not include the required changes in the python code to not symlink umu_run.py into the steam compatibility tool.

[loathingKernel]

Given that we use a script for flatpak in steam's compat tool, using symlinks for the system packages is of no value and just convolutes the code. Consider using a script in that case too. The makefile is already creating it and installing it for the package.

[R1kaB3rN]

Given that we use a script for flatpak in steam's compat tool, using symlinks for the system packages is of no value and just convolutes the code. Consider using a script in that case too. The makefile is already creating it and installing it for the package.

It's fixed, but because there was a bug since the launcher would create the symbolic link to the entry point when it had already been created during the build process, resulting in a FileExistsError. This was a failure on my part for not testing it.

using symlinks for the system packages is of no value and just convolutes the code.

Let's please be careful not to reopen our past disagreement about symbolic links, whether that's your intention or not. Because to be honest, I'm still not quite settled or convinced about it and I only let that pass solely because I value your contribution to this project and would like to encourage others to contribute as well. However, if there's any complaints about it from anyone, causes any kind of issue or bugs like you did here, which I doubt, I may have to reconsider it.