The colibri class name for the source name sender constraints changed from SenderVideoConstraintsV2 to SenderSourceConstraints.
The new format is {colibriClass: 'SenderSourceConstraints', sourceName: 'b6746083-v0', maxHeight: 180}

When multi-stream-support is enabled, configure the encodings on all the local video sources.

Also, configure all the video tracks when the user changes the quality settings from UI.

The encodings for local video tracks are confiugured based on the SenderVideoConstraintsV2 constraints received from the bridge. The constraints are sourceName based. Also ignore enableLayerSuspension flag since it has been deprecated and layer suspension has been enabled by default. Also having it off makes screensharing on Chrome in unified plan not work as expected.

* feat: Adjust setReceiverConstraints to use new format

* add ReceiveVideoController spec

* rename prioritizedSources to onStageSources

* call FeatureFlags.init in specs and update description

* provide a default flags argument to FeatureFlags.init

* ref(TPC) Configure encodings in one go.
Configure the active state, maxBitrate and degradation preference in one go instead of configuring them separately.

* squash: Address review comments.

* squash: fix a comment.

This is needed for screensharing to work as expected on chrome in unified plan.

If the application is using the new receiver constraints, propagate the height constraint to the p2p session as well.

Do not send old format constraints if no constraints are set before the channel is initialized.

Fixes the case where the old format height constraint is sent on join for a jvb media session.

Use the new receiver constraints unless it is explicitly disabled through config.js.

Add the ability to send the bridge messages for the receiver video constraints in the new format directly.

There were cases where the bridge was sending the same constraint multiple times causing redundant calls to getParameters/setParameters on the RTCRtpSender.

Translate the 'LastNChangedEvent', 'SelectedEndpointsChangedEvent' and 'ReceiverVideoConstraint' messages into the new 'ReceiverVideoConstraints' message that invokes the new bandwidth allocation algorithm in the bridge that is described here - https://github.com/jitsi/jitsi-videobridge/blob/master/doc/allocation.md. useNewBandwidthAllocationStrategy=true in config.js will invoke the translation in the client.

All the send video constraints for the client, i.e., what simulcast streams will be enabled based on constraints received on the bridge channel, will be handled by the SendVideoController class.
The receive video constraints like lastN, selectEndpoints and receive video resolution will be handled by the ReceiveVideoController class.

* feat: Apply max bitrates on video sender
Add the ability to control the max bitrates on the video sender through a config.js videoQuality setting.

* ref: Use '_' prefix only for internal methods

* feat: Set degradation preference on video senders
Use 'maintain-framerate' for camera tracks and 'maintain-resolution' for desktop tracks

* ref: apply cached video contraints and degradation preference on unmute
Since the sender encodings are available only after the renegotiation is complete (on chrome/safari), constraints/preferences have to be applied after renegotiation is complete.

Refactors the way send/receive video constraints are managed and puts the high level
logic in a separate module. See QualityController.js for high level overview on how
the constraints are managed now.

Adds events to JitsiConference fired whenever it starts new jvb/p2p session.

Adds event to JingleSessionPC.js when remote party signals receive max frame height.
Also adds signaling of the local recv preference for the p2p mode(only existed for JVB).