Allow audio decoder to seek backwards

[NicolasHug]

Towards #549.

Changes are quite subtle, but I'm fairly confident they work as expected, since they pass our robust tests. I'll make sure to write some solid documentation around the mechanisms involved eventually.

Benchmarks results show no perf hit

Duration: 13s
torchcodec: med = 8.05ms +- 1.13
torchaudio: med = 12.27ms +- 0.51

Duration: 13s
torchcodec: med = 4.20ms +- 0.91
torchaudio: med = 7.21ms +- 0.58

Duration: 2m11s
torchcodec: med = 28.26ms +- 0.95
torchaudio: med = 45.72ms +- 0.89

Duration: 1h27m
torchcodec: med = 1046.49ms +- 66.00
torchaudio: med = 1746.49ms +- 22.55

Benchmark code is the same as in #538, I'm not benchmarking the "backwards seeking" logic.

[NicolasHug]

I've convinced myself that we should actually keep this helper instead of doing the conversion. Thoughts?

[scotts]

I think that's fine - then what we're testing is that decoder behaves the same when it seeks to a location "fresh" versus having to seek from some given location, including backwards. That seems reasonable.

[NicolasHug]

Note that this is INT64_MIN and not 0, because some packets actually start before 0. In one of our assets the first packet is at -1024.
I noticed that passing an arbitrary low value like -999999 makes FFmpeg unhappy and raise and error, but INT64_MIN seems to be understood and correct (although I haven't found docs on this).