Add threading support for the `video` command

[FreezyLemon]

The basic idea is that we hide the two decoders behind a Mutex, and let the worker threads decode two frames (one per decoder) to calculate the SSIMU2 score. It's written so that the Mutex lock is dropped as quickly as possible after decoding the frames, so another worker thread can start decoding ASAP. The resulting score value is sent via result_tx to result_rx, which is used in the main thread to accumulate the scores and handle the terminal output.

Some notes:

• I've tested a few approaches to multithreading, but it looks like there's always some memory bottleneck which is hit somewhere between 4 and 5 worker threads on my machine. I've "confirmed" it's a memory bottleneck by downclocking my RAM, which significantly reduced the performance ceiling.
• With every thread holding up to 2 frames at a time, it's very easy to hit OOM if you just enter a high threads value. I've thought about clamping the parameter to something like (1, 20) but then decided against it, as this is a user error.
• Minor point but I'm not sure if I should avoid using drop like that. Other languages with "automatic" memory management generally discourage manual deletion of variables. There's other ways to drop the value (move some of the code into a new scope, for example) but this seemed to be the easiest and most obvious way

[FreezyLemon]

Rebased & addressed the feedback. The Mutex now also guards a usize that is incremented every time both decoders successfully decode and return a frame to the score calculation. This frame index is used to guarantee scores in frame decode order (graphing is reliable again). And the verbose println exists again