Bump GLFW to 3.4, fix Wayland Configurations

[wi-re]

This PR should address #12 and several other issues mentioned via Zulip.

The major changes are:

Bumping GLFW from 3.3 to 3.4: This is done as older versions of GLFW under Wayland did not properly support adding window decorations (this is a general change to how client and server side decorations work). GLFW 3.3.9 and 3.4 added support for libdecor to automatically populate the window decorations. This will require installing the libdecor-0-dev and libdecor-0-plugin-1-cairo packages via snap, or similar. Note that on some older Ubuntu versions, e.g., 20.04, these packages do not exist even though Wayland is supported, so those configurations will not have working window decorations and we cannot fix this.

Changes to CMake Setup: To add proper support for Wayland we need to force GLFW to use either x11 or Wayland depending on the system as relying on the GLFW build script in this case can lead to issues (this may be avoidable in some cases by manually modifying their scripts but this is not a solid fix in every configuration). To do this we use the XDG_SESSION_TYPE environment variable that should be set on all sane systems. If this variable is not set, which is the case on WSL2, we can use this behavior to force Wayland by default, which makes WSL2 setups run. This should not break any previously non-working setups.

Added USE_WAYLAND and USE_X11 CMake Options: In case someone wants to manually force either X11 or Wayland we now have a configuration flag for this purpose.

This branch has worked on WSL2 (Ubuntu 20.04), Windows, XUbuntu 24.04 (X11), MacOS and Arch + Hyprland (on some setups) thus far and has broken on none.

[wi-re]

Included bandaid fix for #17 due to lack of support for immediate mode on Wayland systems currently, see here.

This commit also fixes the CMakeLists.txt change to unset the old style GLFW defines.

[wi-re]

I've now also bumped the webGPU version to a newer version to be able to query the surface capabilities to address #17 in a more elegant way.

The new behavior is to check if the surface supports an alternative present mode and only in those cases to enable unlimiting the FPS. While this does make the code nicer to use, it did require significant changes to the surface setup, i.e., the newer webGPU versions no longer use swapchains.

This is a much more significant change so this PR will stay open for now without being merged.

Also there is an issue in this version where resizing the window leads to warnings being generated due to intraframe changes of the framebuffer and this does not appear to have a straight forward solution when using ImGui.