Add internal timer system for async timeout handling

[bjosv]

Adds a pre-allocated timer pool that supports multiple concurrent async timers through a single adapter hook.
This allows adding additional timers (cluster topology refresh, c-ares DNS timeouts, health checks) without requiring adapter changes.

Timer framework (commit 1)

• Pre-allocated pool of timers, sorted linked list by deadline
• One timer processed per call (safe if callback frees the context)
• Uses CLOCK_MONOTONIC / QueryPerformanceCounter

Async timeout migration (commit 2)

• Separate connect_timer and command_timer with own callbacks
• Connect timer cancelled on successful connect
• Command timer tracks reply count to detect unresponsive servers
• refreshTimeout is now a regular exported function (for TLS .so)
• No adapter changes

Behavior change
Changing command_timeout at runtime no longer affects an already-running timer.
The new value takes effect after the current timer fires.

[michael-grunder]

This is a massive improvement.

I'm still going through it but I have a couple extra commits in a branch on my fork

Just the overflow comment and re-allowing a user to disable a timeout after it has been set. I think we still want that behavior?

[bjosv]

@michael-grunder Moved the valkeyTimerList allocation now, alot better. I also added your improvement commits.

I wonder if its possible to get rid of refreshTimeout and its call in every _EL_ADD_READ/_EL_ADD_WRITE somehow now.
Previously it handled the multiplexing of timers, but now we might just be able to start each timer when connecting and when sending a command.

I think the command timeout could be moved already by starting the command_timer in valkeyAsyncAppendCmdLen instead.

The connect timer is harder since we need to start it in valkeyAsyncConnect*, or when the event-adapter is attached by the user via calls like valkeyPollAttach(). Maybe this was the reason for doing it in refreshTimeout from the start?