DRM: Refacto EME implementation selection mechanism

[peaBerberian]

While debugging a safari issue that in the end seemed link to both DRM and audio track selection of a directfile content, we experimented with the possibility for an application to choose between EME implementation.

For example, an application could decide on Safari to either rely on the latest EME recommendation or on the still-available webkit-vendored API, which are both incompatible to one another.

This was a feature we didn't really want, but what we thought we might have to implement because Safari had issues with both API that could lead to the impossibility to play the content. The RxPlayer couldn't determine which content would work best with which API, but the application could (as it depended on the packager used).

Thankfully, we ended up finding a better solution, relying only on timing audio track switches requests on the application-side instead.

Still, we had the feature ready and though this new API appears unnecessarily complex now that we don't need it anymore, some work on it still appear beneficial to the RxPlayer.
Consequently, this commit removes any notion of the new API but keeps:

• EME polyfills (webkit-vendored and so on) are now only brought into your application when you rely on the "minimal build" if you actually import the EME feature (it makes sense, shouldn't break anything, and just remove some code from your bundle(s) if you don't need decryption)

• The choice of the EME implementation to rely on is now isolated in its own getEmeApiImplementation function based on an implementation's "name", instead of just chosen once at evaluation time, which should make future debugging easier.

• MediaKeys-related clean-up is now always performed with the EME API that was used for the corresponding content.

• The webkit implementation now only rely on the webkitneedkey event for initialization data and not on the encrypted event anymore, as its format is different.

• Switching EME implementation between contents is now a theoretical possibility (though no API exploit this), and we clean-up the previous implementation's side effect when we do so.

• We remove the potentiality of a race condition between setMediaKeys EME API call by awaiting the returned promise when we're removing the previous MediaKeys instance.

• Some minor ContentDecryptor improvements, brought initially when we wanted to attach MediaKeys to the HTMLMediaElement only AFTER the encrypted events - which is not needed now - but the modifications appeared to lead to a simpler architecture that what we had before.

• Any key system whose name begins by com.apple.fps is now considered fairplay, instead of an incomplete enumerated list