refactor: use custom file lock functionality

[R1kaB3rN]

umu-launcher currently depends on the filelock module to ensure that only 1 active umu-run process downloads Proton or the runtime. However, implementing file locking is relatively trivial and we do not care about cross platform file locking, async support, nor timeout support.

[loathingKernel]

Nitpick: Do the locks need to persist through reboots? If not, what do you think of placing the lockfiles in /tmp so they are more likely to be lost after a reboot?

This does not affect normal execution, but should address issues with the lock remaining if outside factors disrupt umu

[R1kaB3rN]

In addition to being able to run on the SD, one of our requirements is being able to run and use umu within a container framework, namely Flatpak and Snap. Those frameworks as well as their corresponding low level sandboxing tools can be configured so that $TMPDIR is a new private tmpfs and can be mounted at a different path. Having our lock files within umu’s host runtime directory avoids any special handling, and guarantees that a lock will always be held when sandboxed.