NAKREPORT doesn't work with packet filter set up with SRT_ARQ_ONREQ

[ethouris]

The problem is that the loss list container is not predicted to work with losses falling in out of order or marked specifically as loss to be reported, as it uses a special case that order of seen losses is the same as order in sequence numbers, which is normally true in SRT, but it's not necessarily true in case of losses reported by filter as irrecoverable.

The loss container must be improved so that meddling inside the loss list, finding losses, breaking up ranges and joining sticky ranges on the fly is possible.