Add a proactor-based async acceptor

[mrabine]

Description:

The current Acceptor and TlsAcceptor only expose a synchronous blocking accept(). This issue tracks the addition of asynchronous counterparts that integrate with the existing Proactor infrastructure.
AsyncAcceptor and AsyncTlsAcceptor will submit an IoOperation::Accept to the Proactor and notify the caller via a plain function pointer with user context (void*) upon completion, avoiding any heap allocation or type erasure on the hot path.
If no Proactor is provided at construction, the ProactorThread singleton is used transparently.

Acceptance Criteria:

• BasicAsyncStreamAcceptor inherits from BasicStreamAcceptor and CompletionHandler
• BasicAsyncTlsAcceptor inherits from BasicTlsAcceptor and CompletionHandler
• Both classes accept an optional Proactor* at construction; if omitted, ProactorThread::proactor() is used
• accept(AcceptCb callback, void* ctx = nullptr) submits an IoOperation::Accept to the proactor and returns 0 on success, -1 on error with lastError set
• Completion callback signature is void ()(Socket&&, void) noexcept — no std::function, no heap allocation
• onComplete() builds a fully connected Socket (non-blocking, TCP_NODELAY set) and invokes the callback with move semantics
• onComplete() for the TLS variant additionally attaches an SSL object with SSL_set_accept_state() called, mirroring BasicTlsAcceptor::acceptEncrypted()
• cancelAccept() cancels any in-flight operation via the proactor; no-op if idle
• close() calls cancelAccept() before closing the underlying fd to prevent dangling fd references in the proactor
• Re-arming for subsequent connections is the caller's responsibility (explicit re-call of accept() from within the callback)