Prep for step-reversing protocols

[lePereT]

What type of PR is this? (check all applicable)

• 🍕 Feature

Description

Extend wait.waitable and stream backends to support “direction switching” readiness, where an operation can block on either readability or writability depending on the underlying state machine (eg. TLS WANT_READ/WANT_WRITE).

Changes:

• wait.waitable: allow step() to return false, want (want is any of 'rd'|'wr'|'any'), pass want into register(), and re-register on each wake-up based on the latest want.
• wait.waitable: support want == 'any' by registering both read + write waiters and unlinking both on completion/abort.
• io.stream: plumb want from backend read_string/write_string into waitable and register on the appropriate readiness (on_readable/on_writable) depending on want.
• fd_backend (posix/nixio/ffi): return want on EAGAIN/EWOULDBLOCK ('rd' for reads, 'wr' for writes).
• Example: enable fibers.scope debug traceback capture in 03-scope-finalisers.lua to aid diagnosis during integration.

Rationale:

• Required for nonblocking TLS handshakes and shutdown where “read” may require writability and “write” may require readability.
• Preserves existing behaviour for simple fd-backed streams while making readiness waiting more expressive and predictable.

Manual test

• 👍 yes

Manual test description

• Ran existing examples locally to confirm normal scheduling and finaliser behaviour remains intact.
• Verified stream read/write against nonblocking fds still progresses correctly; EAGAIN/EWOULDBLOCK now yields a want value and re-registers appropriately.
• Sanity-checked want == 'any' handling by ensuring both registrations are created and unlinked as expected.

Added tests?

• 🙅 no, because they aren't needed

Added to documentation?

• 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?

Nope