Only load the last audio and video segments of a content when seeking after it

[peaBerberian]

The RxPlayer usually loads only media segments containing media data from the current playback position onward.

However, there is an exception to that rule: for the last segment of the content it is possible to load it even if it ends before the current playback position (this may happen for example when audio data ends before video data, and then seeking at the end of the video data, here we may load the last audio segment even if it ends before the current position).

This is done to better handle the ending logic of malformed contents. The browser provides the endOfStream EME API. Calling this API allows to indicate that the last segments have been pushed which then lead to HTML5 "ended" support (both the event and property) on the video HTMLElement along other niceties, such as a more precize duration update.

It is important to call this API after the last chronological segments has been pushed to ensure a proper duration, displaying the last video frame, and other reasons.
As some contents could lead us to a position where we're seeking a little after the last video or audio segment in a content (for example audio ending before video), loading the last segment as a rule regardless of the current position when ending appeared as a solution.

---

However, we found out that this behavior may lead to unwanted side-effects in some peculiar scenarios.
For example, we've seen segments containing only subtitles, ending much before the actual end of the content, taking priority (in that: the segment request was prioritized) over future audio and video segments, though in reality text should probably not be considered important enough here to be prioritized.

This appears to be a minor issue, but when combined with some other problems we're working on, we've seen that it might lead, in cases with an aggressive Garbage Collector (e.g. through the maxBufferBehind option), to a loop where the old text segment is loaded again and again, taking priority over the same future audio and video segments, leading to a very short buffer being constructed (we'll load audio and video segments only once they are soon enough to match the priority of the text one).

Yet the fact is, we don't even need to load the last segment for "non-native" types (like text, in opposition to audio and video). This is because those have no influence over HTML5 video management (which was the main goal behind that last-segment logic).

Thus this commit disable this last-segment logic for buffers that are not audio no video.