Playback stops at EXT-X-GAP tag if GAP exceeds buffering time

If there is a gap across all renditions that lasts longer than the buffered time limit (50s default) the player stops indefinitely in the buffering state. This is of course because buffering is calculated based on the playlist not the samples yet rendering depends on the samples.

This issue is related to #6087 (in that if the gap is smaller than 50s playback simply skips the duration of the audio gap)

### Reproduction Steps

1. Play a VOD sample with EXT-X-GAP duration longer than 50s in all renditions
2. Observe playback stalls in buffering forever

I have sent two sample stream URL's with a gap in all renditions starting at 1:18 seconds into the stream to the Exo developers email address.

### Further Analysis

#### Use Cases
Gaps in the stream happen in broadcast streams for a couple of reasons:
1. **PID drops** — the source transport stream drops an audio PID, this can happen for alternate language tracks
2. **Outages** — drops in the multicast feed, issues with satellites, transcoding broadcast stream. All of these can result in gaps across all renditions. Very possible this can exceed buffered time

ExoPlayer's current behavior (Skipping the media time with an instantaneous jump) is quite reasonable for the *Outages* use case (logging an analytics event would be nice to allow the UX of showing a whisper banner indicating an outage caused the jump). The use cases for *PID drops* are adequately covered in issue #6087

#### Suggested Fix

The `SequenceableLoader` interface needs to understand one or all of its constituent loaders are experiencing a GAP and continue loading across the gap until the discontinuity (first sample after the GAP) is loaded. Here the decision to jump past the discontinuity or play through (if only one rendition has a GAP) can be intelligently made. This may be specific to HLS as DASH appears to be looking at a different approach see issue #4616