Use our own index to seek more accurately when it is available

[ahmadsharif1]

Before this change when the user asks us to seek to some timestamp T, we pass that timestamp down to FFMPEG.
However, we have noticed that sometimes FFMEPG seeks past that timestamp for certain files:
#179
https://trac.ffmpeg.org/ticket/11137
After this change if we have our own index, we use that to seek to the last keyframe before the target frame. This avoids the buggy behavior and seeks are accurate even for the H265 encoded videos.

Benchmarked this change and didn't find changes above the noise level.

# Before
python ~/personal/torchcodec/benchmarks/decoders/benchmark_decoders2.py 
med = 48.34ms +- 7.39

# After
python ~/personal/torchcodec/benchmarks/decoders/benchmark_decoders2.py 
med = 44.17ms +- 6.23

# Benchmark code
$ cat ~/personal/torchcodec/benchmarks/decoders/benchmark_decoders2.py
from time import perf_counter_ns
from torchcodec.decoders import SimpleVideoDecoder
import torch
import os


def bench(f, *args, num_exp=100, warmup=10, **kwargs):
    video_path = os.path.join(os.path.dirname(__file__), "../../test/resources/nasa_13013.mp4")
    decoder = SimpleVideoDecoder(video_path)
    pts_list = [x * 0.5 for x in range(20)]
    for _ in range(warmup):
        frames = [decoder.get_frame_displayed_at(pts) for pts in pts_list]

    times = []
    for _ in range(num_exp):
        start = perf_counter_ns()
        frames = [decoder.get_frame_displayed_at(pts) for pts in pts_list]
        end = perf_counter_ns()
        times.append(end - start)
    return torch.tensor(times).float()

def report_stats(times, unit="ms"):
    mul = {
        "ns": 1,
        "µs": 1e-3,
        "ms": 1e-6,
        "s": 1e-9,
    }[unit]
    times = times * mul
    std = times.std().item()
    med = times.median().item()
    print(f"{med = :.2f}{unit} +- {std:.2f}")
    return med

if __name__ == "__main__":
    times = bench(lambda x: x, num_exp=1000, warmup=10)
    report_stats(times, unit="ms")

[NicolasHug]

Thanks a ton for the fix and for the benchmark @ahmadsharif1.

Unrelated to this PR, but I'm surprised the stddev is so large even over 1000 runs!