* ref(TraceablePeerConnection): rename var to what it is

* ref(ssrc info): get rid of 'ssrc' and 'group' roots

Removes 'ssrc' and 'group' root Objects from "ssrc info" structure.
Also removed redundant 'primarySSRC' from the group.
Do not split and join back and forth the SSRCs, but store them as
numbers.

* feat: add SdpTransformUtil

* ref(rtxModifier): rename "previousAssociatedRtxStream"

* ref(RtxModifier): use for .. of

* fix(SdpConsistency): organize imports

* fix(RtxModifier): organize imports

* ref(JitsiLocalTrack): simplify the expression

* extract MLineWrap (ongoing)

* ref(TPC.extractSSRCMap): some ES6 cleanup

* ref(RtxModifier): use template strings

* doc(SdpTransformUtil): update and fill missing

* ref(SdpTransformUtil): const, template strings

* style(TPC): object formatting

* ref(JitsiLocalTrack): simplify expression + syntax

* ref(TPC): more "extractSSRCMap" improvements

* ref(RtxModifier): const all the things

* ref(SdpConsistency): template strings

* ref(SdpTransformUtil): syntax + other

* doc(SdpConsistency): add throws description

* fix(TPC): broken "extractSSCMap"

* fix(JitsiConference): adopt to Map

* ref(SdpTransformUtil): remove forEachSSRCGroup and static methods

Otherwise, RTX may break setRemoteDescription and the respective
receive video(s) will not render because their packets will be dropped.

This reverts commit 886bc1519d.

Turns out Chrome decides to not choose the maximum possible resolution when
given a range. Oh well!

Otherwise Chrome has been seen using a simulcast layer with a resolution of
240 x 135, which can break implementations not supporting odd resolutions, such
as WebRTC on Android.

Related Chrome issues:
* https://bugs.chromium.org/p/webrtc/issues/detail?id=6651
* https://bugs.chromium.org/p/webrtc/issues/detail?id=7206