Fix T68091: Adding a corrupt video crashes/confuses Blender

The problematic video from T68091 clearly has an invalid stream duration (it would be 55 centuries long if interpreted at 30 FPS, and given that it was recorded with an Android 9 device, it's unlikely that recording started that long ago). I've added a heuristic to check the stream duration against the container duration; if the stream is more than 4x longer than the container, Blender now falls back to the container duration.

We could use MIN(stream duration, container duration), but there might be video files out there where the container duration is less precise than the stream duration; they are measured in different units of time (microseconds for the container vs. frames for the stream).

This diff contains three commits that I intend to keep separated:

• cleanup to make the following commits clearer
• switch frame rate guessing from our own code to the appropriate FFmpeg function
• add the above-described heuristic

F7758185 can be used to test, and will be part of the unit test suite once this patch is accepted.