Refactor/Rename PlaybackObserver to MediaElementMonitor

[peaBerberian]

TL;DR: This is a code simplification proposal to set a single interface for all HTMLMediaElement interactions, under a class named MediaElementMonitor. This is just a merge of the previous PlaybackObserver module (which monitors playback) and of previously direct HTMLMediaElement access (which would now be avoided in profit of calling MediaElementMonitor methods).

---

Based on #1645

I worked on multiple R&D subjects recently that needed a re-thinking of how we interact with the media element in the core logic:

• The "preload" work (to preload a content in-memory before playback).

  Here the idea was to make most core RxPlayer modules work optionally "headlessly" during a preloading phase (without an actual media element to play on), and to then be able to "hot swap" the media element at any point if the content needed to be actually played - with the intent of speeding up loading time for future contents.

• The "Core Dump" work (a planned API to output an extensive snapshot of the RxPlayer state and playback conditions on playback errors - for debugging, logging and advanced experimental mitigations purposes of platform issues).

  Here I needed to be able to access many media properties at once and both their current states but also their last pre-error status.

On both of those subjects, I found that passing around both the media element and a PlaybackObserver everywhere was awkward and unnecessary: the PlaybackObserver already contains the media element and has to be used for some side-effects: e.g. seeking has to go through it.

So I propose here to just define a single interface to the media element.

The most difficult step has been to know what to name that thing. Initially I went with MediaElementInterface, but it didn't seem to be really indicative of what 99% of its use is, which is to monitor playback conditions.
So in the end I just went with MediaElementMonitor. Though it also allows side-effect on the media element (seeking, setting src...)

Not everything is simplified yet (there are still places when I rely on the two), but it's a good first step.

[github-actions]

✅ Automated performance checks have passed on commit e5f5b37b52328b7a821bc1443ed0976951345ef0 with the base branch dev.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name	Mean	Median
loading	29.68ms -> 30.23ms (corrected: -0.790ms, A/A bias: 0.244ms, z: 0.50999)	24.90ms -> 24.90ms (corrected: -0.325ms, A/A bias: 0.125ms, z: 1.13064)
seeking	543.09ms -> 530.60ms (corrected: 35.046ms, A/A bias: -22.550ms, z: 0.65433)	1005.60ms -> 1005.50ms (corrected: 0.600ms, A/A bias: -0.225ms, z: 1.77054)
audio-track-reload	26.02ms -> 25.82ms (corrected: 0.117ms, A/A bias: 0.082ms, z: 0.39452)	25.20ms -> 24.90ms (corrected: 0.075ms, A/A bias: 0.150ms, z: 0.75537)
loading over active content	20.28ms -> 20.15ms (corrected: 0.089ms, A/A bias: 0.041ms, z: 0.26462)	18.10ms -> 17.90ms (corrected: 1.275ms, A/A bias: 0.000ms, z: 0.26462)
large multi-period manifest	77.33ms -> 77.93ms (corrected: -0.481ms, A/A bias: -0.121ms, z: 0.07698)	70.35ms -> 72.95ms (corrected: 4.725ms, A/A bias: -3.975ms, z: 0.07698)
cold loading multithread	43.73ms -> 43.27ms (corrected: 0.502ms, A/A bias: -0.042ms, z: 1.38564)	43.00ms -> 42.40ms (corrected: 0.825ms, A/A bias: -0.250ms, z: 4.05107)
seeking multithread	429.91ms -> 497.30ms (corrected: -77.412ms, A/A bias: 10.021ms, z: 1.61658)	13.75ms -> 18.30ms (corrected: 0.050ms, A/A bias: -0.800ms, z: 0.55811)
audio-track-reload multithread	25.42ms -> 25.23ms (corrected: 0.215ms, A/A bias: -0.027ms, z: 0.63027)	24.90ms -> 24.70ms (corrected: 0.250ms, A/A bias: -0.125ms, z: 1.55403)
hot loading multithread	18.08ms -> 18.03ms (corrected: 0.022ms, A/A bias: 0.030ms, z: 0.28868)	17.80ms -> 17.70ms (corrected: 0.150ms, A/A bias: -0.050ms, z: 0.73612)