feat(wstransport): add support for concurrent accept

[fcecin]

Overview

This PR helps address logos-messaging/logos-messaging-nim#3634 by adding public APIs acceptStream and processHttpRequest to HttpServer.

Also added a "Test accept" test suite which tests both accept and acceptStream with processHttpRequest.

Rationale

Client code that doesn't tolerate the head-of-line blocking of the existing accept API can instead (i) call acceptStream in a loop, in a dedicated task to create remote-client sockets from the server socket, and (ii) spawn new tasks to call processHttpRequest and wait for and process HTTP headers arriving from the client socket (which can take a long time and shouldn't block new remote-client sockets).

Alternatives (tried before):

• Push everything into nim-websock: The most transparent and localized solution to the bug, but it is arguably the ugliest solution; out of nim-websock's scope; not ideal.
• Spawn async tasks on the client to call the existing accept: Even with a fix to Chronos' inability to handle StreamServer.accept multitasking we have observed very weird behavior; in any case, this kind of solution fights Chronos and is not ideal.
• Spawn an HTTP header parsing task inside accept: even if it's still nominally just an accept API, client code still has to asyncSpawn, in addition to the asyncSpawn inside accept. HttpRequest object becomes "hollow" and needs to be populated later; clients need to know that a future inside HttpRequest must be awaited before accessing its data fields.
• Callback/handlers: will be deprecated from nim-websock; doesn't solve the problem of the client still having to duplicate HTTP header handling code.