I did some testing and this seems to work okay, but it *is* different to
GLFW. GLFW seems to lose "IsCursorOnScreen" for one frame upon pressing
alt+tab over the window, without a different window covering it. SDL
seems to have a more reasonable behavior for this case. Either way it's
an edge case and I don't know the exact way to fix, likely requires
internal GLFW changes.

* cmake: For SDL, disable rlgl_standalone

* cmake: Only build rlgl_standalone when on Desktop, and not shared libs

* Screen/world-space related functions rename

* Update raylib_api.* by CI

---------

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

* CMake: Remove USE_WAYLAND option

* Consistency fix

* Fix oversight

The fingerId from SDL was used as an index into the CORE.Input.Touch
arrays, but it's an opaque / arbitrary int64, way bigger
than MAX_TOUCH_POINTS, so the first non-simulated touch event would segfault.

* Update GLFW to 3.4 (draft)

* Add _glfwConnectNull() function to rglfw.c

* Update rglfw.c

* Update Makefile

* Makefile: Replace USE_WAYLAND_DISPLAY with DISABLE_WAYLAND

* Revert "Makefile: Replace USE_WAYLAND_DISPLAY with DISABLE_WAYLAND"

This reverts commit 9e79abde78.

* GlfwImport.cmake: Replace GLFW_USE_WAYLAND with GLFW_BUILD_WAYLAND

* Update rglfw.c

* Output platform selected by GLFW to TRACELOG

* GLFW has removed Mir support

* Change sanitization check for `ExportDataAsCode`

I opted to use `isalnum` function since it should handle most cases. It
cannot however handle cases of files beginning with numbers.

* Update `ExportDataAsCode` condition

* Reinsert comment on `ExportDataAsCode`

Tutorial on how to use bones as sockets to calculate the position of something.

I tested this with CMake. I don't know if the examples makefile
currently handles this case.

Raylib VAPI has been updated to support all features added by Raylib 5.0

Currently, every example fails linking likeso:

[  3%] Linking C executable audio_mixed_processor
/usr/bin/ld: ../raylib/libraylib.a(raudio.c.o): undefined reference to symbol 'exp@@GLIBC_2.29'
/usr/bin/ld: /usr/lib/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

Apparently, linking libm explicitly is the solution.

* Added gamepad rumble to rcore_desktop.c and rcore_desktop_sdl.c
Still need to add to the rest of the platforms.

* Add SetGamepadVibration warnings to unimplemented platforms.

* Added MAX_GAMEPAD_VIBRATION_TIME
The rumble in SDL2 will continue for MAX_GAMEPAD_VIBRATION_TIME unless the user cancels it with a call to SetGamepadVibration(0.0f,0.0f,0.0f)

* Cast float duration value to Uint 32

* Changed defines from int to float and fixed typo

---------

Co-authored-by: Gideon Serfontein <gse@newspacesystems.com>

Fixed a grammatical error by removing "are" to change `... but some are have multiple purposes ...` to `... but some have multiple purposes ...` in `textures/textures_image_generation`

The purpose of this directory in GLFW is to provide some headers that
"mingw.org" doesn't. Raylib has long been unable to build with mingw.org
due to using certain symbols that aren't exposed in their headers.
(_ftelli64 and _access, among others.). Mingw-w64 already has the
necessary headers included, and doesn't need any of these external
implementations. For some reason, this also causes the following error
when building with Visual Studio's clang:

clang  -c rglfw.c -Wall -D_GNU_SOURCE -DPLATFORM_DESKTOP -DGRAPHICS_API_OPENGL_33 -Wno-missing-braces -Werror=pointer-arith -fno-strict-aliasing  -std=c99 -O1 -Werror=implicit-function-declaration -I. -Iexternal/glfw/include -Iexternal/glfw/deps/mingw
In file included from rglfw.c:61:
In file included from ./external/glfw/src/init.c:30:
In file included from ./external/glfw/src/internal.h:331:
In file included from ./external/glfw/src/platform.h:31:
In file included from ./external/glfw/src/win32_platform.h:70:
external/glfw/deps/mingw\xinput.h:227:26: error: a parameter list without types is only allowed in a function definition
  227 | void WINAPI XInputEnable(WINBOOL);
      |

If the last -Iexternal/glfw/deps/mingw is removed, the build works fine.

So, this workaround causes other problems, while not actually helping
raylib.

0bb605cd79/src/CMakeLists.txt (L272-L279)

GLFW's CMakeLists.txt first checks if either dinput.h or xinput.h are
provided by the toolchain, before telling the compiler to search for
headers in that directory. For EVERY compiler that can build raylib,
this is true.

In summary: This directory causes issues when building with some
compilers, and every toolchain that needs this workaround can't build
raylib anyway.