Implement simulcast

[mickel8]

In simulcast, client (in our case browser) can send multiple encodings of the same source. Each encoding can have different resolution, bitrate etc.

SFU responsibility is to convey to each peer version of source encoding that this peer is able to process.

The task is to implement SFU side of simulcast.

Resources that might be useful:

• https://www.youtube.com/watch?v=6COV44AORlo
• https://datatracker.ietf.org/doc/rfc8853/
• https://webrtchacks.com/sfu-simulcast/
• https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#rid-attribute (search for rid)
• https://datatracker.ietf.org/doc/html/rfc8829#section-3.7
• https://datatracker.ietf.org/doc/html/rfc8853#section-5.1

[mickel8]

From RFC 8829, Section 3.7:

   JSEP currently does not provide a mechanism to configure receipt of
   simulcast.  This means that if simulcast is offered by the remote
   endpoint, the answer generated by a JSEP endpoint will not indicate
   support for receipt of simulcast, and as such the remote endpoint
   will only send a single encoding per "m=" section.

   In addition, JSEP does not provide a mechanism to handle an incoming
   offer requesting simulcast from the JSEP endpoint.  This means that
   setting up simulcast in the case where the JSEP endpoint receives the
   initial offer requires out-of-band signaling or SDP inspection.
   However, in the case where the JSEP endpoint sets up simulcast in its
   initial offer, any established simulcast streams will continue to
   work upon receipt of an incoming re-offer.  Future versions of this
   specification may add additional APIs to handle the incoming initial
   offer scenario.

This means that to implement support for simulcast we have to implement support for Initial Offers sent by a browser (membraneframework/membrane_webrtc_plugin#10).

cc @mat-hek