SignalR should allow managing of connections by UserGroup

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

Right now, I can send messages to an individual user using their NameIdentifier and `Clients.User(nameIdentifier).SendAsync`. I can also send messages to a group of connections using a group name and `Clients.Group(groupName).SendAsync`. However, unless I'm missing something, I can't send a message to a group of users (user as identified by nameIdentifier, not connection ID) at the SignalR level.

### Describe the solution you'd like

I'd like to be able to send messages to a group of users (user as identified by nameIdentifier, not connection ID) at the SignalR level.

### Additional context

Yes, this can of course be done with a roll-your-own backplane, track your own users as a group, and send to multiple users in SignalR according to the group you've defined for yourself. But the beauty of Groups and Users in SignalR is that they inherently support scaling up to multiple SignalR server instances and your code doesn't have to worry about ensuring that the message gets sent out to all SignalR instances.

If I roll-my-own backplane, I have 2 options:
1) Implement my own mechanism for grouping users by nameIdentifier, then when I want to send a message to all users in that group, use `Clients.Users(nameIdentifiers)`. This will work, but each time a server wants to send to the group, it'll have to go to a backplane or database to retrieve the list of all users in that group; it can't use SignalR's existing scaling architecture to just "send to all users in this UserGroup", which would be more convenient and efficient.
2) Use `Clients.Group(groupName)`. Each time a user joins a group, I add their connection ID into that named group, then send to that group to send to all group users. But what about when the user reconnects with a new ID? I need to worry about adding their new ID back into the appropriate groups. And what about when they leave the group? I know their current ID, but not any others associated with their nameIdentifier that may have been added. Seems like this won't really work.

If, however, SignalR offered the concept of UserGroup, I'd add a user to a group when necessary, remove them when necessary, and when I needed to send a message to all group users by nameIdentifier, I'd send it to that UserGroup. A user disconnecting/reconnecting is fine because their nameIdentifier is still in that UserGroup so nothing needs to happen. A user leaving is fine, because my server instance can just remove that nameIdentifier from the UserGroup. And when I need to send a message to all users in the UserGroup, I don't need to spend extra resources going off to a backplane or DB; it's utilizing the one that already exists because I've scaled up SignalR and setup a SignalR backplane already.