HTTPReactorServer: use async notification dispatcher for request handling

[matejk]

Summary

HTTPReactorServer currently invokes the request handler synchronously on the
SocketReactor thread. A slow handler stalls every other connection bound to
that reactor.

Proposal

Make POCO's existing AsyncNotificationCenter available as an optional
dispatch backend so users can opt into worker-thread handler execution when
they need it. Reactor threads then only do I/O readiness.

Per @aleks-f's feedback: the dispatcher stays synchronous by default
(switching it on globally would spawn extra threads and risk surfacing
thread-unsafe handler code in existing deployments). The setting is explicit
opt-in, configured on the server / HTTPServerParams. When enabled, both
the request side and a future non-blocking response-write path (driven by
WritableNotification) can run async.

No change to the HTTPRequestHandler contract.

[aleks-f]

@matejk Just make sure the notification side remains (default) synchronous. Making it async can cause lots of end-user trouble, from spawning many threads to hitting thread-unsafe code. But with Async NC, there should be a way to run reactor with both side being async if that's what user explicitly wants.

[matejk]

Agreed -- updated the proposal so async dispatch is strictly opt-in (sync remains the default to avoid surprising existing handlers with concurrent invocations). When the user opts in, AsyncNotificationCenter would back both the request-handler side and a non-blocking response-write path.