Fixes #5.

Allows to explicitly enable/disable seek-stress tests.

This allows to more easily run all the major test cases from testdata-8,
testdata-10, testdata-12 and testdata-multi,
excluding checkasm, headers, oss-fuzz-* and testdata_seek-stress.

Meson 1.3.0 deprecates [0] str.format() use with File objects [1].
Starting with 1.4.0 [2] there will be an explicit method [3] to query
the path.
Alternatively, fs.name() from the FS module could be used for meson
versions >= 0.59.0. [4]
Since our minimum version is 0.49.0 though, we'll use this workaround.

[0] https://mesonbuild.com/Release-notes-for-1-3-0.html#unified-message-strformat-and-fstring-formatting
[1] https://github.com/mesonbuild/meson/issues/12406
[2] https://github.com/mesonbuild/meson/pull/12408
[3] https://mesonbuild.com/Reference-manual_returned_file.html#filefull_path
[4] https://mesonbuild.com/Fs-module.html#name

There's no need to use a special list. This also means the vq_suite gets
seek_stress treatment.

Test ids are supposed to be unique, so failed tests can easily be
identified.

test10218_6914 contains both 8 and 10-bit frames.

Signed-off-by: James Almer <jamrial@gmail.com>

Calling meson with no command is deprecated since 0.64.0

  * Update images
  * Deduplicate code

The minimal meson version has been 0.49 for over a year.
Ref: dav1d!1081

MD5 hashes match for all 10 oppoints when comparing aomdec and dav1d.

Currently seek-stress is only implemented for IVF files. On section5 or
annexb files an error message from the ivf demuxer is printed which
includes the first 4 bytes of the file in ASCII and hex representation.
The section5 example starts with 0x12 which is an ASCII control
character, leading to problems in the JUnit XML file automatically
generated by meson.

Fixed by 69ff474a7f3a7ccc61c5e6881e45e0afe693f352.

=================================================================
==71453==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x629000009a40 at pc 0x00010dad0530 bp 0x7ffee25c2ab0 sp 0x7ffee25c2278
READ of size 948 at 0x629000009a40 thread T0
    #0 0x10dad052f in __asan_memcpy+0x1af (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4652f)
    #1 0x10d8b6cf7 in backup_lpf lr_apply_tmpl.c:88
    #2 0x10d8b6157 in dav1d_lr_copy_lpf_16bpc lr_apply_tmpl.c:148
    #3 0x10d9064f3 in dav1d_filter_sbrow_deblock_rows_16bpc recon_tmpl.c:2076
    #4 0x10d908e96 in dav1d_filter_sbrow_16bpc recon_tmpl.c:2154
    #5 0x10d723442 in dav1d_decode_frame_main decode.c:3331
    #6 0x10d724123 in dav1d_decode_frame decode.c:3396
    #7 0x10d72d11a in dav1d_submit_frame decode.c:3767
    #8 0x10d7ce192 in dav1d_parse_obus obu.c:1608
    #9 0x10d90dbe9 in gen_picture lib.c:394
    #10 0x10d90db12 in dav1d_send_data lib.c:424
    #11 0x10d63b888 in LLVMFuzzerTestOneInput dav1d_fuzzer.c:164
    #12 0x10d63c7c1 in main main.c:94
    #13 0x7fff20626f3c in start+0x0 (libdyld.dylib:x86_64+0x15f3c)

0x629000009a40 is located 0 bytes to the right of 18496-byte region [0x629000005200,0x629000009a40)
allocated by thread T0 here:
    #0 0x10dad2b73 in wrap_posix_memalign+0xb3 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x48b73)
    #1 0x10d71ee5f in dav1d_alloc_aligned mem.h:66
    #2 0x10d71a8f6 in dav1d_decode_frame_init decode.c:3127
    #3 0x10d723d13 in dav1d_decode_frame decode.c:3378
    #4 0x10d72d11a in dav1d_submit_frame decode.c:3767
    #5 0x10d7ce192 in dav1d_parse_obus obu.c:1608
    #6 0x10d90dbe9 in gen_picture lib.c:394
    #7 0x10d90db12 in dav1d_send_data lib.c:424
    #8 0x10d63b888 in LLVMFuzzerTestOneInput dav1d_fuzzer.c:164
    #9 0x10d63c7c1 in main main.c:94
    #10 0x7fff20626f3c in start+0x0 (libdyld.dylib:x86_64+0x15f3c)

Having the exact commit hash in the logs helps with debugging.

==747== ERROR: libFuzzer: timeout after 61 seconds
    #0 0x4b9340 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/ubsan/ubsan_diag_standalone.cpp:33:3
    #1 0x464278 in fuzzer::PrintStackTrace()
    #2 0x4484d9 in fuzzer::Fuzzer::AlarmCallback()
    #3 0x7f9f2cbeb3bf in libpthread.so.0
    #4 0x7f9f2cbe6375 in futex_wait_cancelable /build/glibc-eX1tMB/glibc-2.31/sysdeps/nptl/futex-internal.h:183:13
    #5 0x7f9f2cbe6375 in __pthread_cond_wait_common /build/glibc-eX1tMB/glibc-2.31/nptl/pthread_cond_wait.c:508:14
    #6 0x7f9f2cbe6375 in pthread_cond_wait@@GLIBC_2.3.2 /build/glibc-eX1tMB/glibc-2.31/nptl/pthread_cond_wait.c:638:10
    #7 0x4bbe94 in drain_picture /src/dav1d/src/lib.c:353:13
    #8 0x4bb942 in dav1d_get_picture /src/dav1d/src/lib.c:447:16
    #9 0x4baf71 in LLVMFuzzerTestOneInput /src/dav1d/tests/libfuzzer/dav1d_fuzzer.c:182:16
    #10 0x449d03 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long)
    #11 0x435472 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
    #12 0x43b13e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long))
    #13 0x464a12 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #14 0x7f9f2c9e50b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16
    #15 0x41071d in _start

=================================================================
==59763==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62c000027a40 at pc 0x000100ccd5e3 bp 0x700008ffd670 sp 0x700008ffce38
WRITE of size 320 at 0x62c000027a40 thread T4
    #0 0x100ccd5e2 in __asan_memcpy+0x262 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x465e2)
    #1 0x100ab1e4c in backup_lpf lr_apply_tmpl.c:96
    #2 0x100ab11c1 in dav1d_lr_copy_lpf_16bpc lr_apply_tmpl.c:148
    #3 0x100b01573 in dav1d_filter_sbrow_deblock_rows_16bpc recon_tmpl.c:2076
    #4 0x100b15984 in dav1d_worker_task thread_task.c:602
    #5 0x7fff2060b953 in _pthread_start+0xdf (libsystem_pthread.dylib:x86_64+0x6953)
    #6 0x7fff206074a6 in thread_start+0xe (libsystem_pthread.dylib:x86_64+0x24a6)

0x62c000027a40 is located 0 bytes to the right of 30784-byte region [0x62c000020200,0x62c000027a40)
allocated by thread T1 here:
    #0 0x100ccfb73 in wrap_posix_memalign+0xb3 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x48b73)
    #1 0x10091a0bf in dav1d_alloc_aligned mem.h:66
    #2 0x100914ff0 in dav1d_decode_frame_init decode.c:3090
    #3 0x100b12d9d in dav1d_worker_task thread_task.c:496
    #4 0x7fff2060b953 in _pthread_start+0xdf (libsystem_pthread.dylib:x86_64+0x6953)
    #5 0x7fff206074a6 in thread_start+0xe (libsystem_pthread.dylib:x86_64+0x24a6)

Thread T4 created by T0 here:
    #0 0x100cc958a in wrap_pthread_create+0x5a (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4258a)
    #1 0x100b3e22d in dav1d_open lib.c:214
    #2 0x100834618 in LLVMFuzzerTestOneInput dav1d_fuzzer.c:131
    #3 0x1008357c1 in main main.c:94
    #4 0x7fff20626f3c in start+0x0 (libdyld.dylib:x86_64+0x15f3c)

Thread T1 created by T0 here:
    #0 0x100cc958a in wrap_pthread_create+0x5a (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4258a)
    #1 0x100b3e22d in dav1d_open lib.c:214
    #2 0x100834618 in LLVMFuzzerTestOneInput dav1d_fuzzer.c:131
    #3 0x1008357c1 in main main.c:94
    #4 0x7fff20626f3c in start+0x0 (libdyld.dylib:x86_64+0x15f3c)

The bitstream is valid and features proper Frame Headers on every frame, so
the should be skipped by the decoder.