Remove RTCRtpEncodingParameters API from BCD

[queengooborg]

This PR removes the RTCRtpEncodingParameters API from BCD. This feature is a type (ex. a dictionary, enum, mixin, constant or WebIDL typedef) that we have explicitly stated not to document separately from the feature(s) that depend on it, as they are virtually invisible to the end developer.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[hamishwillee]

@queengooborg This adds features for RTCRtpSender.setParameters() encodings parameter object, including: active, dtx, fec, maxBitrate, maxFramerate, priority, rid, rtx, scaleResolutionDownBy, ssrc. I presume these are tested for versions.

However the RTCRtpEncodingParameters are also used in:

• RTCRtpSender.getParameters() - we should test, but I would expect to see the same values under "return_object_property_encodings" as you have above, because before setting params you should first get them.
• RTCPeerConnection.addTransceiver(trackOrKind, init) - the init has sendEncodings which is the same encodings again - so we need a mirror there (again tested).

Can you update/test those cases too?

See also #19584 (comment)

Docs are in progress in mdn/content#30080

[hamishwillee]

FF - the properties like fec, rtx, srcc are in web IDL (https://bugzilla.mozilla.org/show_bug.cgi?id=1230184#c30) but not actually exposed - that bug is to remove them. From https://bugzilla.mozilla.org/show_bug.cgi?id=1863534#c3 the encodings that FF actually supports is active, maxBitrate, maxFramerate, priority, rid, scaledResolutionDownBy.

Because I know the intent is to remove them, we have know way of knowing when they may have existed or not in reality, and they are non-spec, I am completely removing those entries.

[hamishwillee]

FYI @queengooborg The corresponding docs merged, so these questions need to be addressed please.

[Elchi3]

Safari 11 should probably be used (was 11 in the dictionary too)

[Elchi3]

Thanks @queengooborg and @hamishwillee! 👍 I've cleaned this up so that it can be merged. We can always send follow-up PRs to correct the data further.

[hamishwillee]

Thanks very much!