Public API review for SignalR C++ Client

[analogrelay]

Epic #5301

We need to do a public API review for the SignalR C++ client to make sure we're happy with it.

[BrennanConroy]

Couple notes from PR reviews:
http_request timeout - should we have a separate parameter on send instead, or CTS-like class we return from send?
websocket_transport - "trampoline" instead of recursion in receive loop (would prevent stack overflow from bad code), #8420 (comment)
Threading - Currently relying on the websocket/http stack to do threading, we should decide on who owns threading and how to do it
websocket_client - on_receive vs receive, receive means we control the loop, on_receive means websocket_client providers need to handle the loop
set_disconnected - the callback should probably accept an exception