fix(cast): Added existence checks for MediaDecodingConfig.{audio|video} in decodingInfo().

[JulianDomingo]

See #4790.

To be honest, I'm failing to understand how a TypeError can happen here (this is occurring in a Casted Apple Music, non-AES-128 stream, so EME), since:

1. The problematic code lines aren't reachable unless MediaDecodingConfig.keySystemConfiguration is set.
2. MediaDecodingConfig.keySystemConfiguration is only set if drmInfos are provided:
   

   shaka-player/lib/util/stream_utils.js

   Lines 659 to 666 in 68f10a1

   	const videoDrmInfos = variant.video ? variant.video.drmInfos : [];
   	const audioDrmInfos = variant.audio ? variant.audio.drmInfos : [];
   	const allDrmInfos = videoDrmInfos.concat(audioDrmInfos);
   	// Return a list containing the mediaDecodingConfig for unencrypted variant.
   	if (!allDrmInfos.length) {
   	return [mediaDecodingConfig];
   	}

during manifest parsing (showing HLS for example):

shaka-player/lib/hls/hls_parser.js

Lines 1003 to 1016 in 68f10a1

	const keyFormat =
	drmTag.getAttributeValue('KEYFORMAT') || 'identity';
	const drmParser =
	shaka.hls.HlsParser.KEYFORMATS_TO_DRM_PARSERS_[keyFormat];
	const drmInfo = drmParser ?
	drmParser(drmTag, /* mimeType= */ '') : null;
	if (drmInfo) {
	if (drmInfo.keyIds) {
	for (const keyId of drmInfo.keyIds) {
	keyIds.add(keyId);
	}
	}
	drmInfos.push(drmInfo);

Regardless, requestMediaKeySystemAccess() will never report a variant is supported if contentType is null/empty string (as per https://w3c.github.io/encrypted-media/#get-supported-capabilities-for-audio-video-type). So the polyfill implementation behaves the same as before this change.

[github-actions]

Incremental code coverage: 100.00%