Expand websocket adapter, ensure connections/disconnections can be done dynamically, establish better pattern for dynamic subscriptions for use in other adapters

Many adapters have static, wiring-time connection requirements, e.g. you need to provide a url or channel or topics at wiring time and cant make new connections dynamically. Starting with the websocket adapter where it is more (most?) relevant, we should establish a better pattern for dynamic subscriptions. This will be of particular importance in the upcoming redis adapter.

We may want to develop a common structure for subscriptions, though it will like have implementation-dependent details. As a simple example for websockets:

class ConnectionRequest(struct):
    url: string
    action: ActionType # Connect, Disconnect, Ping, etc
    persistent: bool  # e.g. 
    on_connect_payload: Any
   ...

Then adapters will have the following structure:

%%{init: {'flowchart': {'defaultRenderer': 'elk'}}}%%

flowchart LR
    requests["Requests for new connections/paths"]
    data_from["Data from existing connections/paths"]
    data_to["Data to connections/paths"]
    adapter["Adapter/Manager"]
    status["Status or Status of Requests"]
    requests --> adapter
    data_to --> adapter
    adapter --> status
    adapter --> data_from

For redis its even more complicated, but still the same overall pattern

%%{init: {'flowchart': {'defaultRenderer': 'elk'}}}%%

flowchart LR
    key_and_data_to_write["Key + Data to write"]
    key_hash_data_to_write["Key/Hash + Data to write"]
    key_to_read["Key to read"]
    key_and_hash_to_read["Key/Hash to read"]
    key_to_sub["Key to sub"]
    adapter["Adapter/Manager"]
    data["Data from read request"]
    data_from_sub["Data from sub"] 
    status["Status or Status of Request"]
    key_and_data_to_write --> adapter
    key_hash_data_to_write --> adapter
    key_to_read --> adapter
    key_and_hash_to_read --> adapter
    key_to_sub --> adapter
    adapter --> status
    adapter --> data
    adapter --> data_from_sub

Start by reading the existing websocket adapter and its wiring model, then compare the proposed request/adapter/status flow with the upcoming Redis adapter needs. The work is done when connections and disconnections can be requested dynamically and the resulting subscription pattern is suitable for reuse by other adapters.