desktop-ui: Threading rework

[jcm93]

Rearranges ares's main run loop, putting emulation in its own dedicated thread that is separate from the main/GUI thread. This updates ares to somewhat more modern application practices. This rework should have an array of benefits, including increased UI responsiveness, improved energy efficiency/performance, and increased compatibility with various modern APIs and frameworks for rendering, input, and audio.

Details

Generally, this PR implements a fairly simple approach to threading, using nall::thread's pthread-like semantics and several basic recursive mutexes. For this initial implementation, we use very coarse locking on the emulation thread, combined with very limited access to the emulator state from the main and other ares threads, allowed to occur between emulator run loop iterations. Synchronization on the emulator state is managed via programMutex.

Since this mutex is held for the duration of the primary work loop, including while the thread is suspended, the GUI thread should try to never acquire the program mutex unless absolutely necessary. Doing so with regularity will incur a severe UI responsiveness penalty. For destructive updates like driver settings updates, memory writes, and game loads/unloads, we acquire it. For other cross-thread communication, we try to synchronize using other methods that do not incur a significant performance penalty.

Window resizes triggered via the emulation loop synchronize with the _needsResize atomic. Status messages are passed by acquiring the messageMutex. vBlanksPerSecond is also now an atomic<u64>.

Input continues to poll on the main thread for compatibility with existing code. Access to the input system is managed via inputMutex.

Known Issues

Draft status as this is still a work in progress, but PRing now for visibility, feedback, and to consolidate any issue tracking. There are likely kinks left to work out; testing is appreciated.

- Cores are loaded on the main thread before being run on the emulator thread; this causes issues for paraLLEl-RDP, which expects that the thread to initialize Vulkan is also the thread that will make RDP calls. Addressed.

- Memory editor currently does not have access to the program mutex; reads and writes are unsynchronized. Addressed; memory editor synchronizes on writes but reads occur in a thread-unsafe fashion.

- The Clang thread sanitizer still reports a couple data races in Metal and OpenGL; further testing with other Ruby drivers is needed to make sure resource access is properly managed, particularly with respect to the output framebuffers. A larger examination of locking in other parts of ares is probably necessary, but I think out of scope for the first iteration of this rework.

• The gdb server seems to still be working fine, but could probably use more testing.