Use SDL_DelayNS for lower thread jitter on non-Windows platforms

[harrislegobrick]

This PR uses SDL_DelayNS to improve thread pacing on all platforms except Windows where a high resolution timer was already used. As of libsdl-org/SDL@c8f5f6d, SDL_DelayNS no longer busy-loops and instead uses the high precision OS delay functions.

Tested to work the same on Windows and have lower thread jitter on Linux, but I was unable to test mobile and macOS.

Runs fine under both SDL2 and SDL3 because according to @hwsmm in the SDL3-CS bindings update ppy/SDL3-CS#165, SDL_DelayNS doesn't require SDL3 init, but this PR will limit to only SDL3 for now to not mix SDL2 and SDL3. When o!f switches fully to SDL3 then the Windows specific implementation can be removed as SDL_DelayNS uses the same Windows high resolution timers.

Testing:

• Windows
• macOS
• Linux
• iOS
• Android

[Susko3]

SDL_SYS_DelayNS uses nanosleep() on Unix (non-windows). But the windows implementation uses SDL_GetTLS -- it's hard to check that this works as expected without SDL_Init.

https://github.com/libsdl-org/SDL/blob/f79f21217bbb7aba82d68076af5119956b44d046/src/timer/windows/SDL_systimer.c#L39

The comments specifically mention that there is a race condition if SDL_Init is not called. Guess how many threads will call SDL_DelayNS in multi-threaded mode :)

https://github.com/libsdl-org/SDL/blob/6da4d94abffe4d2d53862f4e66eefe9e867fa1a2/src/thread/SDL_thread.c#L66-L70

Also, this unnecessarily puts SDL code in things not related to windowing and input. I think it's better to just implement the nanosleep() functionality ourselves.

[hwsmm]

I thought using DelayNS is not so bad for non-Windows platforms since Apple, Android, and Linux all use different libc, and struct timespec can be different between architectures/implementations, but I guess I was overthinking then..

I am not opposed of implementing nanosleep bindings natively (this is actually what @harrislegobrick did first, and worked well enough), but we will then have a native timer bindings both for Windows and for Unix platforms in the framework, and this didn't sound so good for me. If adding nanosleep in framework is fine for everyone else, I guess that's a better way forward.

[bdach]

Also, this unnecessarily puts SDL code in things not related to windowing and input.

This was my initial reaction too, I'm not sure I want SDL calls anywhere outside of windowing / input handling. Curious of @smoogipoo's opinion though.

[smoogipoo]

I share similar concerns to the above and would prefer implementing the relevant funcs ourselves.

[bdach]

With three votes against I'm not sure we need any more, I see no further point to this being open at this stage.