gh-74953: PyThread_acquire_lock_timed() recomputes timeout

[vstinner]

The mutex with conditional variable implementation of lock now
recomputes the timeout if acquire(timeout=timeout) is interrupted by
a signal.

[vstinner]

macOS job failed with:

0:05:19 load avg: 9.67 [ 99/436/1] test_concurrent_futures failed (env changed) (3 min 15 sec)
(...)
Warning -- sys.stderr was modified by test_concurrent_futures
Warning --   Before: <_io.StringIO object at 0x10d1a5590>
Warning --   After:  <_io.StringIO object at 0x10d822cb0>

I don't know if it's related to the PR.

[vstinner]

PR rebased on main to get fixes for unrelated compiler warnings.

[vstinner]

I'm no longer convinced that this change is needed:

• On Linux, USE_SEMAPHORES macro is defined: use sem_clockwait(), or sem_timedwait()
• If I manually undefine the USE_SEMAPHORES macro to use mutex+condvar implementation, I failed to interrupt pthread_cond_timedwait() with a signal. If it's called with a timeout of 5 seconds and an interrupt is received in 1 second, pthread_cond_timedwait() function does not return EINTR but blocks for 5 seconds.

Locks used in Python call PyThread_acquire_lock_timed() with intr_flag=1: if a function returns EINTR, it returns immediately, the caller checks for signals, and then calls again the function to try again to acquire to lock with a re-computed timeout.

I close my PR. But I wrote PR #94056 to clean-up the code.