Add: Ability to drop old frames

[DawidWesierski4]

Add: Ability to drop old frames

Change the way pipeline TX handles the order of framebuffers. Track
per-frame sequence numbers so transport can dequeue the newest converted
frame instead of always taking the next one, needed as otherwise
we cannot drop frames, as they will not be in order.

Add a new flag to the TX pipeline to enable droping frames when we jump
over epoch. Mostly will aid with user control pacing.

Implemented in a way that only drops one frame in a scenario where late
is detected. This creates limitation for extreamly high drops The stream
will still not adjust immidiately instead doing
send frame | drop frame | send frame | drop frame ...
until we catch up.
(Done mostly as big jumps over more than 2 frames could be undesirable
and if you have that big of a drop ... well this is the leas of your
troubles).

All above done in pipeline as the purpose of the api pipeline is to
smoothe the library tight timing requirements from the user
applications.

Fix the st20p wrong user timestamp reporting in frames snapped to
the next frame.

if times given by the application looks as follows
----|--frame-1--|--frame-2--|--frame-3--|--frame-4--|-...
epoch-1--|--epoch-2--|--epoch-3--|--epoch-4--|...

This causes frames to snap to the next epoch, resulting in incorrect
timestamp reporting where every frame appears to have a "wrong user
timestamp" due to the forward snapping behavior.

Fixes: 88c3566987fd6e773d07d79b67e06391f3037cb2

Add simple tests.
Fix the usdt for st40p tx (only to add the spurn event).
Fixes: 921fa0d0f21de48d385680c215365b55ca5f033d

[Sakoram]

I think it would be beneficial to add an option in which pipeline mode does not drop frame by itself but it calls the callback and the app handles the situation in its own way e.g. by dropping some frame or slowing down differently.

[DawidWesierski4]

Good idea

[DawidWesierski4]

Done