[WIP] Initial work on adding server side group management to channels

[bruinbrown]

In the current channels implementation, we're limited to sending to specific clients identified by a framework provided socket ID. There are instances where we want to be able to treat connections as a higher level construct and message a group of connections at once. Some examples of this include:

• A chatroom where a group relates to a private message conversation
• A game where a group is a running game server These are tasks where we want to perform the management of groups on the server to limit either the security impact of sending all messages to all clients or to improve performance by not sending all global messages.

In this PR, I've started an implementation of server side management of groups, I suspect that there will still be some API changes needed before this is production ready though.

A group is a child of a channel. A channel can have many groups and an individual connection can belong to many groups. Clients can be added to and removed from groups at any time in the application's lifetime and is not just limited to adding or removing during connection or disconnection events. Groups are identified by a composite key of channel path and group name. Groups are currently a serverside only concept, e.g. the server can broadcast a message to all clients within a group but a client does not have the same ability, therefore there is no concept of server side message subscriptions for groups.

This PR adds the following changes:

1. A change to the channel computation expression to expose an on_connected and on_disconnected handler which are invoked during the channel lifecycle
2. A change to the ISocketHub API which exposes functions to add a connection to a group, remove a connection from a group and send a message to all members of a group.
3. Internal changes to the socket API to maintain a thread safe dictionary of client group membership.

This implementation still needs some cleanup and API changes as mentioned above hence why the PR is marked as WIP. I would be interested to hear thoughts on the current implementation and how we could further improve this.

[Krzysztof-Cieslak]

Hey @bruinbrown, is this something you're still interested in working on? It's fine if not, I'll probably pick up parts of this implementation and finish it in such case.