CreateFFmpegInteropMSS methods will get out of hand if we add a lot more options

There are already a whole bunch of parameters already in these methods. I have some new features in mind which would require to add even more parameters. If we continue to evolve the library and add all new options here, we will run into problems, this will be confusing.

I would propose to move to a different initialization model, like this:

var ffmpeg = new FFmpegInteropMSS();
ffmpeg.ForceVideoDecode = false;
ffmpeg.ForceAudioDecode = true;
ffmpeg.AllowMultipleAudioStreams = true;
ffmpeg.CorruptPackageThreshold = 100;
await ffmpeg.OpenStreamAsync(stream);  // this could be async to prevent UI blocking
var mss = ffmpeg.GetMediaStreamSource();

This is more like what you expect from framework WinRT classes.
The old CreateFFmpegInteropMSS could be left for compatibility reasons.

What do you think?

Start by locating the existing CreateFFmpegInteropMSS methods and their callers, then review how the listed options are initialized and how OpenStreamAsync and GetMediaStreamSource would fit the proposed lifecycle. Done means providing the new initialization model while retaining the old CreateFFmpegInteropMSS path for compatibility.