Added support for forwarding groups in AudioBridge

[lminiero]

This PR introduces the concept of "groups" in the AudioBridge, exclusively for RTP forwarding purposes. In a nutshell, it allows you to tag users somehow, so that when you forward the mix via RTP, you can choose whether the mix should include everyone (default behaviour and how it worked so far) or a mix only including users with the same tag. This is something we found a need for in some specific applications, where we needed a finer grained management of audio streams we'd receive from the mixer, as opposed to a mix of just everyone.

This grouping functionality needs to be enabled, and is disabled by default, so if you don't care about it nothing should change. Should you be interested in using this, you need to add a groups array when creating the room (either statically or dynamically), where the array must contain a list of strings each representing a tag for the room, e.g.:

{
    "request": "create",
    "room": 1234,
    "groups": [ "red", "green", "blue" ],
    [..]

The request above would create a new room with three separate groups: red, green and blue. When groups are enabled in a room, all join requests MUST contain a valid group, as the room needs to be able to tag participants accordingly as they come in. Participants can move from one group to another using a configure request, so this makes for a dynamic behaviour.

Notice that, as far as participants are concerned, nothing changes: they still talk to everyone else, and can hear everyone else, so groups are irrelevant to them. These groups are only relevant when you start creating RTP forwarders, since with groups enabled it means you can now send a mix of everyone in the room, or a mix only containing red, green or blue participants. If you specify a valid group property in an rtp_forward request, then only a mix containing participants tagged with that group name will be forwarded; omitting the group will forward the whole mix instead.

I tested this briefly and it seems to be working as expected, but we plan to test more. You're encouraged to give it a try yourself as well, in case you think it might be useful to you too. Notice that you should expect some more CPU usage out of this: mixing itself shouldn't be impacted much (when groups are enabled, we simply mix the groups first, and then mix those to get the global mix, so it's basically the same effort), but the fact there are different mixes means we need different encoders, and so the more groups you have, the more the mixer thread may have to work. As such, for now we've arbitrarily limited the feature to 5 groups maximum, which is probably way more than anyone will ever need.

Feedback welcome!

[lminiero]

Merging.