WebSocket Streams: restore on_open/on_close/on_error/on_reconnect lifecycle callbacks

[Bogsey]

Summary

The modular WebSocket-Streams client provides no way to observe the connection
lifecycle. An abnormal disconnect (WSMsgType.ERROR/CLOSE, or a silent EOF on a
network drop) just breaks out of the detached receive_loop task and is
swallowed — consumers get no signal. The SDK only reconnects on its 23h timer or a
serverShutdown event, never on an abnormal close, so an app can sit on a dead
socket with no callback to react to.

The legacy connector exposed on_open/on_close/on_error/on_ping/on_pong;
the modular client dropped that surface.

Related reports

• Websocket connection exceptions are not handled by the user neither the on_error callback is called. #293 — on_error callback is not called
• Web socket stream hangs when disconnected from the network midway #227 — hangs on a mid-stream network drop
• Futures WebSocket: Multiple stream types return successful SUBSCRIBE ACK but send zero data frames #526 — no disconnect signals, complicating detection

Proposal

Add four optional callbacks to ConfigurationWebSocketStreams
(on_open, on_close, on_error, on_reconnect), fired from WebSocketCommon.
Fully additive — every param defaults to None, so default behaviour is unchanged,
and ConfigurationWebSocketAPI's public signature is untouched. Callbacks are
invoked defensively so a raising user callback can't kill the reader loop. The SDK
distinguishes a planned reconnect (fires on_reconnect) from genuine abandonment
(fires on_close) internally, removing the guesswork consumers currently do
against connection.reconnect / reconnect_tasks.

I have a working implementation with tests an docs.
Happy to open a PR if this direction is acceptable.