rtpjitterbuffer: make sure not to drop packets based on skew

One of the jitterbuffers functions is to try and make sense of weird network behavior.

It is quite unhelpful for the jitterbuffer to start dropping packets itself when what you are trying to achieve is better network resilience.

In the case of a skew, this could often mean the sender has restarted in some fashion, and then dropping the very first buffer of this "new" stream could often mean missing valuable information, like in the case of video and I-frames.

This patch simply reverts back to the old behavior, prior to 8d955fc3 and includes the simplest test I could write to demonstrate the behavior, where a single packet arrives "perfectly", then a 50ms gap happens, and then two more packets arrive in perfect order after that.