WIP: rtpjitterbuffer: Fix timer expiration

I ran into a problem when using the rtpjitterbuffer where it never serviced the DEADLINE timer, causing it to buffer up all data until the system ran out of memory and never pushing out anything. I'm not sure what exactly is needed to run into this, but I believe a network clock (same source) used by sender and receiver pipeline, and using the RTP_JITTER_BUFFER_MODE_SYNCED mode sometimes triggers this. It seems to depend on the value of the base_time when starting the stream.

When this happens I see two timers (in this case I broke in with gdb after about 8 seconds):

gstrtpjitterbuffer.c:wait_next_timeout:4043: rtpjitterbuffer1: 0, 2, 32022, 5124095:34:33.339210744 diff:-0:00:08.766098051 gstrtpjitterbuffer.c:wait_next_timeout:4048: rtpjitterbuffer1: 1, 0, 33809, 0:00:10.036655920 diff:+0:00:01.640898741

Timer 0 is the DEADLINE timer, which based on diff is about 8 seconds overdue. Timer 1 is an EXPECTED timer. wait_next_timeout() however keeps handling only the EXPECTED timer, and the DEADLINE timer never gets handled despite being overdue. This is because comparing the absolute GstClockTime value in TimerData against now makes it appear to be way in the future, even though it's expired already. Comparing against the (signed) difference solves this problem consistently.