matroska: Provide audio lead-in for some lossy formats

Various audio formats require an audio lead-in to decode it properly. Most parsers would take care of it, but when a container like matroska is involved, the demuxer handles the seeking and without its own lead-in handling would never even pass the lead-in data to the parser. This commit provides an initial implementation of that for audio/mpeg, audio/x-ac3 and audio/x-eac3 by calculating the worst case lead-in time needed from known samplerate, potential lead-in frames need and the maximum blocksize possible for the format (as we don't parse that out exactly in matroskademux) and seeking that much earlier in case of accurate seeks. This is especially important for NLE use-cases with GES.

If accurate seeking to a position that happens to have a video keyframe, it'll go back to the previous keyframe than needed, but with typical video files that's the best we can do anyway without falling back to scanning the clusters, as typically only keyframes are indexed in Cueing Data. If the media doesn't have a CUE, then we bisect for the cluster to seek to with the same modified time as well in case of accurate seeking, ensuring sufficient lead-in. This code path is typically hit only with (suboptimal) audio-only matroska files, e.g. when created with ffmpeg, which doesn't add a CUE for audio-only mkv muxing.