Add representationListUpdate event for the v4

[peaBerberian]

While migrating some Canal+ application to the future v4.0.0 version, I noticed that an event, triggered when the list of available Representations associated to a currently-chosen track changed, was missing.

---

Let's consider for example an application logic which stores information on the currently available qualities (so Representation) of the current video track.

With the v4 it can constructs its list any time the video track is initially set or changes for any Period, simply by respectively listening to the newAvailablePeriods event (for when it is initially set) and to the trackUpdate event (for when it is changed).

This seems sufficient at first.

But now let's consider that we're playing encrypted contents, and that one of the Representation of those current video tracks became un-decipherable. Here, an application won't be able to select that Representation anymore, so it generally will want to remove it from its internal state. However, there was no event to indicate that the list of available Representations had changed.

---

I thus decided to add the representationListUpdate event. Exactly like the trackUpdate event, it is only triggered when that list changes, i.e. not when the track was initially chosen.

The exact semantic (and thus documentation wording) is even more blurry than that sadly: this event is sent when the list of Representation MAY HAVE changed. As in, it may also be sent when the exact same Representation are in fact available for that track.

This last part is because implementing a logic checking that it does have changed is doable, but costs more effort (in terms of code writing, performance, storage of previous event etc.) than it should save (I expect that event listener to be relatively idempotent where it matters, as in: triggering two times the same event should not lead to an issue).

Yet I still prevent most of those false positives by:

1. checking that the event is only sent once for each track type (e.g. "audio", "video"...) and Period couple
2. checking that the corresponding track is actually the currently-chosen one for that Period.

[peaBerberian]

Though I like the simplicity (as in, the RxPlayer do less black magic) and event-rich nature of that new v4 API which allows an application to do almost[1] everything on their side, I realize that due to that inner simplicity, application developers have now to have some understanding of what the RxPlayer is doing internally.

For example in the scenarios evoked in this PR's message (having a reactive list of available video qualities at all time), an application has to know what a Representation is, roughly what a Period is, and that the list of Representation is linked to a track.
With those information, it then has to think about listening to an event indicating when the initial track is chosen, when it changes AND when it didn't but the Representation list might have been updated, to have a truly reactive list of available qualities (though I don't think that being the most reactive and up-to-date is always worth its cost, compared to obtaining the data just in time, but that's a whole other debate).

I still prefer it personally to just a availableVideoBitratesChange event of the v3 though, which on the contrary was too smart internally and was too restrictive (only bitrates are listed).

We also could trigger the representationListUpdate event initially when the track is first selected, but I prefer the avoidance of chaining event listeners of overlapping responsibilities here and the issues it could create both in the RxPlayer (what if the track is changed in between those events by an event listener? Though in all honesty, this is detectable) and in an application.

In the end, maybe that to facilitate the exploitation of such API, tutorials in our documentation might need to be written?

[1] I could also have went further by triggering the event when any list changes regardless of if it is on the currently-selected track or not, but I considered that too hard-to-rely-on and too unhelpful - perhaps wrongly - for application developers