Add Ruby thread scheduler priority patch

What does this MR do and why?

Adds ruby/ruby#15840 as a Ruby patch for 3.3, 3.4, and 4.0 builds. This is an alternative fix to bugs.ruby-lang.org #21685.

The previous fix (ruby/ruby#15294) deferred the thread switch and relied on a timer thread to wake up later and perform the switch if the original thread was still blocked. This new approach switches immediately but lets the original thread retake control (aborting the transfer) if the new thread hasn't taken control yet.

Benefits reported upstream:

• Simpler: no new threads, no test changes needed.
• No magic numbers (no 50usec delay).
• More efficient control transfer when it does need to happen, due to a slow call: direct to the new thread rather than indirected through the monitor thread.

Backport details

The 4.0 patch is the upstream diff applied as-is. The 3.3 and 3.4 patches are backports that account for two changes in the older schedulers:

• thread_sched_to_waiting_common was already refactored to delegate to thread_sched_to_waiting_common0 (shared with the dead path), so the new runnable_hot_th assignment is lifted into _common before the delegation rather than being inlined.
• In 3.4 only, the upstream context line thread_sched_set_locked was renamed to thread_sched_set_lock_owner.

See gitlab#594030 for more context.

Checklist

• (If applicable) Add patches if required for upgrading Ruby version in https://gitlab.com/gitlab-org/gitlab-build-images/-/tree/master/patches/ruby.