[Proposal] [v4] Lazily send newAvailablePeriods

[peaBerberian]

This is a relatively simple to implement optimization that may be brought to the v4 beta.

The idea is that the newAvailablePeriods event and the getAvailablePeriods methods - which allow an application to select the right audio/video/text track or quality for any so-called "Period" in the content (for example on a live channel, a film may have more qualities and dynamic ranges than the ad that comes before) - may trigger performance issues on some very large Manifests.

Until now, both communicated about all new Periods seen in the last loaded Manifest.
This is fine, but it may be sub-optimal in a future where a lot of Periods (with themselves a lot of track choices and themselves a lot of quality choices) might be present. There, we would potentially spend a lot of time inside the application choosing for the right track and quality as soon as the Manifest is first loaded (this is only theoretical as of now though, current Manifests seen in the wild do not have sufficient complexity for this becoming an issue for now).

Yet in most if-not-all usages I can think of, the application doesn't really care about the quality and track choice of other Periods as long as those Periods are not yet loaded by the RxPlayer.
To take an example, if you begin loading a live channel at the time of a film, you generally at this point only want to select the track and quality relative to this film - and not e.g. relative to the still-available ad that came before this film that you probably will never play.

If ever the RxPlayer starts considering other Periods, the newAvailablePeriods event would still be sent before their first segments are loaded - so no regression there, and the application can still select the right track and quality at the right time.

---

This PR implements just that. The idea is to only send newAvailablePeriods events for Periods when they begin to be considered by the RxPlayer (as in: their segments will start to be loaded), and not just when the RxPlayer has heard of it through the Manifest, like before.
Likewise, getAvailablePeriods only report Periods that have been sent through a newAvailablePeriods until now.

Because I've been thinking of that trick since the start of the v4, the API documentation was already accounting for that implementation, so no API breakage here.

---

The main issue I could think of with this new logic is that it is not possible anymore for an application to just list all the Periods currently known in the Manifest, or - even if I cannot think of one real world use case - being able to list/select a track or quality well before the RxPlayer starts considering a Period.

However for both of those cases, work-arounds are possible:

• we may in the future add a parameter to getAvailablePeriods to be able to list ALL Periods seen in the MPD.
• The various tracks API may act on Periods not advertised through newAvailablePeriods events as long as the application is in possession of its id (actually they can right now do just that, it already works!) - which they might just do thanks to the new aforementioned getAvailablePeriods parameter
• there still would be a small hole in the API there, as Manifest updates may lead to supplementary Periods without being yet announced through events, and the application might thus not know when to call getAvailablePeriods again - though this does seem easily fixable (event anouncing a Manifest refresh?)

Yet I don't know if this is a real thing applications want.

---

I'm still unsure of whether to merge this because the gain is for now only theoretical.

But at the same time, I don't want applications to rely on the previous behavior right away - in which case this new behavior would be harder to install (even if it doesn't break the API, sometimes applications are known to rely on empirical behavior).
At least, if we merge this, it shouldn't break code if we ever rollback it for simplicity's sake.