Better interfaces for blocking network operations like `accept`

Nobody has claimed this yet.

This is to track a problem noticed by #116 (specifically https://github.com/MSRSSP/litebox/pull/116#discussion_r2086154617): blocking operations like `accept` need us to store an `Arc` (with `Socket` itself containing the fd) in the shim FD table, so that it is not holding the lock on the FD table while being blocked.

Some amount of API re-designing should be able to allow us to divorce the blocking part from the actual fd itself, so that the shim layer does not need to deal with this sort of behavior.

I believe I have an API design that should be able to clean this up (essentially, being able to reserve an immutable (but lifetime-free) token that can _then_ be used for a singular blocking call), but I need to think more about it, thus marking this as a discussion _and_ an enhancement.

(Also just for tracking, related: #31)

Start with issue #116 and its linked discussion, then inspect the shim FD table and the accept path described here. Compare the existing Arc/Socket ownership behavior with related issue #31; done means an agreed API design that separates the blocking call from the fd without retaining the FD-table lock.

Written by the indexing model from the issue text.