splitmuxsink: not sure GAP events are handled correctly

Submitted by Xavier Claessens `@xclaesse`

Reading that code, I find 2 things supsicious:

GAP events are not catched in handle_mq_input(), that means ctx->in_running_time won't be updated. In case of a long gap, that means it's going to queue other streams a lot because the stream with a gap won't be considered ready to let GOPs out. I think in_running_time should be set to gap's timestamp+duration, no?
GAP's duration is not taken into account in handle_mq_output(). In the case of a long gap, that means out_running_time will stay in the past, and complete_or_wait_on_out() won't send EOS until we get the next buffer/gap on that stream which could freeze the pipeline for some time.

I'm not really sure how gap events works, so maybe I'm just wrong here.