rtpbasepayload: fix sequence numbers after a flush

After a flush, the sequence number of the first message sent should be seqnum_base, if seqnum_offset is set manually.

Without this change the first message sent after a flush could have the wrong sequence number. E.g. when using GST_RTSP_SUSPEND_MODE_RESET, the pipeline is PAUSED, a seqnum-offset is set, and the pipeline then goes to PLAYING with a different range header (resulting in a flushing seek). The reason for this is that payload prepares a buffer with the correct sequence number and after this the flushing seek starts, removing the buffer with the correct sequence number. Then the next buffer prepared will have the wrong sequence number.