Move mouse handling to core and add MacOS mouse support

[angelo-wf]

This was originally intended to just add MacOS mouse support, but ended up changing quite a few things:

• Move mouse handling to the core instead of being in the UI
  • Add a IMouseManager (like iKeyboardManager)
  • Add MacOS, Windows and Linux (X11) implementations of this manager, based upon the GlobalMouse*Impl from the UI
  • Add creating the OS-specific one to EmuAPI.cpp (like how it is done for keyboard as well)
  • Add functions for getting/setting/capturing/etc the mouse to InputApi.cpp and matching entrypoints in the UI
  • Use these functions instead of GlobalMouse in the UI
  • Remove the (now unused) GlobalMouse
• Move Sdl-related items from Linux to a new directory Sdl, as these are shared between Linux and MacOS
  • Update makefile to compile contents of Linux only when actually compiling for Linux, and add X11-library to linker flags
  • Remove a #ifdef __APPLE__ block from code that now no longer gets compiled on MacOS
• Update mouse management in UI to also work with the software renderer (as MacOS always uses it)
  • This also allows it to work pretty much fully on Linux
  • On Windows, locking the cursor does not work properly and the cursor-image does not update correctly, but compared to not working at all it is at least a bit better (I don't think the software-renderer is being used often (or at all) on Windows anyway)
  • When using the hardware-renderer, mouse support works just like it did before on Windows/Linux (as far as I tested)
• Add GetPixelScale, used for the MacOS implementation to work around oddities in Avalonia on Retina-screens
• Capturing the mouse now return if it succeeded, and if it didn't, it no longer acts as if the mouse was captured anyway

The reason for moving the mouse handling to the core was because being able to just write Obj-C++ (for the MacOS support) was easier, and only having MacOS go through the core felt weird. It also makes it so the core-library is the only library loaded by the UI (it no longer calls into user32.dll / libx11.so) and the Windows/X11 implementation also looks a bit cleaner now that it does not have to go through C#. The other changes pretty much just came up as part of it.

I have tested it on Linux and MacOS by compiling with the Makefile, and on Windows by using Visual Studio Community 2023. It compiles, runs and functions on all three.

[SourMesen]

Thanks for all the work you put into this!

At first glance this looks fine - the only reason this code was in the UI originally was because on the old winforms UI this allowed me to not have platform-specific code for Windows vs Linux, but it had to be changed to platform-specific code to work around issues I had with Avalonia, so putting it in the core is fine.

I'm unfortunately pretty busy with RL stuff this week and then away for a couple of weeks after that, so I probably won't have time to review/test/merge this until the last week of April or so.

Thanks again for taking the time to improve the macOS build!

[angelo-wf]

I have enabled Github actions in my fork, and it turns out the GCC-Linux build is failing for this branch.

As far as I can see, it does not have any problem with the code itself, but when linking it fails to properly find the X11-library and gives a bunch of errors about not finding X11-functions. This is somewhat odd, as it apparently has no problem finding the headers as it compiles everything fine, and the Clang-builds link just fine. I can see that -lX11 is added to the link-command as well. I tried adding libx11-dev as a dependency to be installed, but this did not help either and the log shows it as already being installed. As far as I am able to find, adding -lX11 is all that should be needed so I'm not quite sure why GCC is not working.

I still want to mess around with it a bit more (maybe the location of the library is not on the default search path?), but the Linux system I have is on Ubuntu 20 and there GCC fails to compile Mesen at all (as noted in the action file as well) so I am not able to test it locally. I do remember locally compiling things with GCC that need X11 and adding -lX11 was enough to make it link.

[angelo-wf]

Turn out it was a silly issue, forgot that libraries need to go at the end of the link command. GCC compilation now works again