SFrame transform algorithm shouldn't operate on JS frames

[jan-ivar]

While working on #285, I noticed the existing SFrame transform algorithm operates on RTCEncodedAudioFrame and RTCEncodedVideoFrame interfaces. This makes no sense as this algorithm should work without any JS exposure.

Leaving this as an item to tackle separately from #285, as we may wish to preserve some of it for when we add support for both sframe and script transform at the same time.

[alvestrand]

While those interfaces are not Web-exposed, it seems just make-work to me to add language saying "these algorithms work on objects that for all intents and purposes are excatly the same as RTCEncodedAudioFrame and RTCEncodedVideoFrame".

(Note - the transform algorithm refers to the ability to run on a BufferSource, but the only reference to it is from a place that says that it passes a frame. So it's not clear that this third alternative can ever be exercised.)

[jan-ivar]

Agree this is largely editorial, and can be fixed without observable impact.

[k-wasniowski]

@jan-ivar @alvestrand what about per-packet approach? Would it mean new abstracts RTCEncodedVideoPacket and RTCEncodedAudioPacket should be defined ?