DRM: re-implement singleLicensePer handling

[peaBerberian]

DRM: re-implement singleLicensePer handling

This update is build on the DRM refacto started in #1042 and fixes some minor issues that could be encountered in a singleLicensePer: "content" mode.
It also paves the way for the future singleLicensePer: "periods" mode.

In particular, it does the following things:

Optimization on the in-memory MediaKeySession cache when in singleLicensePer: "content" mode

The in-memory cache of MediaKeySessions presented by the LoadedSessionsStore - which basically allows faster loading of already-loaded content by re-using a recently-created MediaKeySession before relied only on the initialization data for identification purposes.

This means that false negatives could occur (in that: cache miss where it should have been a hit) in the singleLicensePer: "content" mode (which implies that a single license request will actually retrieve all keys linked to the content), if when re-loading the content a different initialization data is initially encountered.

This would be a false negative here because even if this is different initial initialization data than before, the already-created MediaKeySession still should have received the key to decrypt that other quality.

This is now fixed by linking a MediaKeySession in that cache both to the initialization data linked to it and to all key ids that are explicitely (i.e. in the fetched license) AND implicitely (i.e. in the Manifest file when in a singleLicensePer: "content" mode yet not in the license) linked to it.

This is done through the declaration of a new structure, the KeySessionRecord, which can be "associated" to supplementary key ids at any time, and which contains an isCompatibleWith method to quickly check if newly encountered initialization data and/or key id is actually compatible to an already-created MediaKeySession.

MediaKeySessions loaded (persisted ones) AND retrieved from our memory cache now are not subject to the singleLicensePer option.

All persisted MediaKeySessions as well as all those kept in our in-memory cache were before subject to the same singleLicensePer rules than the current content that is being loaded.

This means that technically, a license fetched for a previous content in a singleLicensePer: "init-data" mode (the default), could be wrongly inferred to be a singleLicensePer: "content" one if a new content compatible with it was loaded in that mode. This would result in the impossibility to use more than the one key stored with that MediaKeySession.

This issue is described by the problem 1 of the #1031 issue. The problem 2 of that issue is also fixed here.

To fix this, the RxPlayer does now two things:

1. A cached or persisted MediaKeySession will now be linked in the corresponding cache to all known key id that are linked to it either implicit or explicit (description of both term higher in this message).

2. Only MediaKeySessions receiving fetched license will now follow the singleLicensePer rule, all other type of sessions (loaded or retrieved from cache) will only be linked to the key id known at the time the caching has been done.
   This could mean relatively rare false negatives when a re-loaded content in a singleLicensePer: "content" mode contains key ids previously unheard of, but I found this was the safest solution.

Write skeleton for the future singleLicensePer: "periods"

One of the goal of that big implementation was also to pave the way for more complex singleLicensePer modes, as we plan to do for the v3.27.0 (#1028). The main differences are that the ContentDecryptor (the new EMEManager) now also receives Manifest-related structures in the initialization data emitted to it and perform all the blacklisting by itself.

This allows it to e.g. know about implicit key ids (keys that should have been in the license according to the singleLicensePer mode but which aren't) without necessitating a round-trip with the Init module.

Remaining issues

One unfortunate side-effect of the current implementation, is the creation of a lock to only allow one initialization data at a time until either the right MediaKeySession is obtained (either created, loaded, or retrieved from cache) in singleLicensePer: "init-data" mode or until the license's keys are available in singleLicensePer: "content" mode. This could mean unnecessary waiting when a persistent MediaKeySession is being loaded, and even more when we have troubles loading it - which is a frequent occurence on some set-top-box.

I'm sure that we could write a less strict lock though, I just didn't take the time to do it.

[peaBerberian]

This PR now fixes completely #1031 and is not a WIP anymore.