Improve "direct" audioTrackSwitchingMode compatibility by re-seeking

[peaBerberian]

Some RxPlayer users had an issue of unaudible audio after an audio track switch on Chrome when the audioTrackSwitchingMode option was set to "direct" (meaning that the track switch will happen - roughly - in place after a small rebuffering the time to load the new audio segments).

That issue seems to be at the browser-level (or may even be at a lower level), but as it can be prevented in the RxPlayer with no much disadvantage, it is still a win to work-around it at the RxPlayer-level.

---

Lately, while PoCing an HLS media player personal project, I tried a new technique which seems to fix this issue reliably.

When changing the audio track, here's the new behavior in my PoC:

1. The application switches the audio track through the player's API
2. The player stop loading the old audio track and begins removing all audio data previously buffered.
3. Once the browser validate this removal operation, the player performs a seek to a very close position, just to force the "flushing" of lower-level buffers
4. The audio data from the new audio track is now pushed (after it has been loaded of course) to the audio buffer.
5. Once that push operation is validated in the buffer, the player seeks again to force a flush again.

The first flush thus prevent from still having the lower-level buffer considering old data in the previous track, the second one fixes the muted audio issue - for some reasons. Most of the time no interruption is visible/audible and when it is, it just seems linked to the audio track switch and does not seem shocking.

---

For the RxPlayer, only the first flush was performed until now.

This commit adds the second one, though it does not happen once the new push operation is
"""validated"""" like for the original implementation, but once the media element on the page announces that it has playable data around the current position instead.

This is because implementing the former is much harder in the RxPlayer. There shouldn't be any real difference between the two implementations, though, and I tested it with success on Chrome and Firefox, with various bandwidth settings (to see if it was audible/visible when the audio track switch is quasi-instantaneous for example).