Allow zero rollover in `mpegts-demuxer`

[slifty]

Task

Description

After a few days of a stream the PTS timestamps will roll back to zero; we need to allow for this (the current logic does not allow PTS to go backwards).

One reason for the current explicit increase logic is to handle out-of-order packets, but I'm not sure if that is a real concern for the use case here, we can simply say to the end user that if you provide out of order packets, you may have out of order PTS times.