[pdpix] `demi_wait_any`: Signaled Exit

Context

In most common server-scale scenarios, there will need to be a coordination wrapper around multiple concurrent IO operations, to allow parallel sockets to work independently. This means almost all work will go via wait_any. The threading model means that additional work cannot be initiated during wait_any calls, so: in reality, most consumers would have to use a very low timeout to enable new work to be appended promptly. This means a lot of API calls, plus the boilerplate that comes with each. It also risks too low a timeout not hitting the end of the list (see also: bias and https://github.com/demikernel/demikernel/issues/341).

Proposed Solution

Instead of relying purely on timeout, consider a signal that can pass between the layers. This could be:

1. shared memory (a pointer), which if non-nul, you dereference and check for a value (perhaps simply non-zero meaning "please exit when you can"); this check should probably be volatile
2. some kind of callback (std-call, etc)

I think 2 is both more complex and more risky (thread-theft). Since the timeout is currently sent as a pointer, I also wonder whether it might make sense to simply use a bespoke timeout struct (instead of timespec) that has such a field, to keep the API minimal.

Now, consumers could use a non-trivial (but reasonable) timeout, and use the signal to interrupt more promptly when required, simply by touching the struct that they are using for the timeout (as shared memory).

Start by reading the demi_wait_any and wait_any API entry points, focusing on how the pointer-based timeout is passed through the layers. Compare the shared-memory signal and callback approaches described in the issue, then define the API behavior and completion criteria for promptly signaling exit without relying only on a low timeout.