rtpvp*depay: possibly forward might-have-been-fec PacketLost events

This is ad adaptation of a Pexip patch for dealing with spurious GstRTPPacketLost events caused by lost ulpfec packets: as FEC packets under that scheme are spliced in the same sequence domain as the media packets, it is not generally possible to determine whether a lost packet was a FEC packet or a media packet.

When upstreaming pexip's ulpfec patches, we decided to drop all lost events at the base depayloader level, and where the original patch from pexip was making use of picture ids and marker bits to determine whether a packet should be forwarded, this patch makes use of those to determine whether they should be dropped instead (by removing their might-have-been-fec field).

Spurious lost events coming out of the depayloader can cause the decoder to stop decoding until the next keyframe and / or request a new keyframe, and while this is not desirable it makes sense to forward that information when we have other means to determine whether a lost packet was indeed a FEC packet, as is the case with VP8 / VP9 payloads when they carry a picture id.