[Proposal] Allow seeking through seekTo before the HTMLMediaElement is ready

[peaBerberian]

As #1600 signalled, there's currently no practical way to update the initial position (configured through the startAt loadVideo option) until startAt has actually been applied.

More generally, it's not possible to perform a seekTo call until the initial seek has been performed on the content (the seekTo call will just be ignored).

This PR proposes the following code updates to improve on that situation:

1. Tangentially related, we now schedule a JavaScript micro-task right at ContentTimeBoundariesObserver's instantiation so the caller can catch events that were previously synchronously sent (I'm thinking here of the warnings for the MEDIA_TIME_BEFORE_MANIFEST and the MEDIA_TIME_AFTER_MANIFEST codes).

   Without this, we would wait for the next playback observation, which could happen a whole second later.

2. I noticed that the position indicated through the startAt loadVideo option was bounded so it's inside the [minimumPosition, maximumPosition] range (as obtained from the Manifest). As stated here I personally think this is suboptimal.

   In my opinion, we should let the initial position go outside the range of the Manifest and let the application do its thing based on MEDIA_TIME_BEFORE_MANIFEST / MEDIA_TIME_AFTER_MANIFEST events.

   As to not totally change the behavior, I've only done so for dynamic contents (contents for which segments are added or removed, like live and contents that are being downloaded locally).

   VoD contents continue to have the previous behavior for now.

3. I added a "seek-blocking" mechanism to the MediaElementPlaybackObserver and made all seek operations, including the one from seekTo go through it.

   The idea is that when it is blocked (as it is initially), we'll delay any seek operation (by marking it as a "pending seek") and only seek to the last one of those once the unblockSeeking method is called (when the RxPlayer considers that the initial seek should be done).

   I also had to add getPendingSeekInformation method, sadly. I feel that we could do without it if we're smarter about things, but I wanted to avoid changing too much code here.

   I also thought about reworking the initial seek so it is completely handled by the MediaElementPlaybackObserver - as it could make everything simpler - but I chose for now to implement that less disruptive "seek-blocking" mechanism.

   Note that technically, we could still have an application directly updating the HTMLMediaElement.prototype.currentTime property, or even a web feature such as picture-in-picture doing that. I ensured that this eventuality did not break anything. Still, there will be a preference for pending seeks performed through the MediaElementPlaybackObserver over such "HTML5 seeks" performed during that time (if there is a "pending seek", we will apply it regardless of if an "HTML5 seek" happened since then).

I'm now unsure if the getPosition or getCurrentBufferGap API should now return that planned position. I did nothing for those yet.