cuda: add psnr_cuda, ssim_cuda and ciede_cuda feature extractors

[BardieJoensen]

This PR adds three CUDA feature extractors so PSNR, SSIM and CIEDE2000 can run in the same GPU pass as the VMAF features, instead of forcing a separate CPU pass (and, with libvmaf_cuda in ffmpeg, a second decode of both inputs):

• psnr_cuda — GPU port of psnr. Integer SSE reduction on device (vectorized grid-stride loads, one atomic per block), scoring math unchanged on the host, so scores are bit-exact vs the CPU extractor — now asserted for PSNR and MSE at 8/10/12/16-bit across YUV420P/YUV422P/YUV444P, with APSNR aggregates compared as well. It is also verified on 500-frame real SDR/HDR clips, y/cb/cr. Supports the CPU extractor's options (enable_chroma, enable_mse, enable_apsnr, reduced_hbd_peak, min_sse). The APSNR flush emits only via vmaf_feature_collector_set_aggregate, so it is idempotent under the threaded+CUDA double flush (cuda: don't flush CUDA feature extractors twice when a thread pool is present #1553).
• ssim_cuda — GPU port of float_ssim, replicating the iqa reference operation-for-operation: box decimation with symmetric borders (fused with the float conversion, so the full-resolution float image is never materialized), 11-tap separable valid-mode Gaussian with double accumulation and float rounding between passes, and the exact float/double mixing of _iqa_ssim (float-typed reference operations use explicit __f*_rn intrinsics so nvcc cannot contract them into fma). Also bit-exact vs the CPU extractor in all testing, and deterministic run-to-run (per-block tree reduction + sequential host sum over block partials). Supports enable_lcs, enable_db, clip_db, scale.
• ciede_cuda — GPU port of ciede. One fused kernel does the nearest-neighbor chroma upsample, YUV→Lab conversion and per-pixel ΔE, with per-block double partials pooled sequentially on the host into the 45 − 20·log10(mean ΔE) score (identical frames yield +inf, matching the CPU extractor — note this also means the pooled mean/max serialize as null in JSON output whenever any frame is identical, for the CPU and CUDA extractors alike, while harmonic_mean stays finite). The shared chroma-upsample index math now correctly treats horizontal and vertical subsampling independently, with YUV420P and YUV422P regression coverage. Unlike the other two, this port is tolerance-validated rather than bit-exact: ciede is dominated by libm transcendentals, which round differently between glibc and CUDA regardless of precision, and FP64 throughput makes a faithful double port impractical on consumer GPUs (1/64 rate). Device math runs in float32 — the CPU reference truncates every intermediate to float anyway — and measured agreement is within 3e-5 on the per-frame score against the CPU extractor on real content (the included test asserts 1e-3). For reference, the CPU extractor measures ~4 fps at 4K with 16 threads (scalar libm, no SIMD variant); the CUDA extractor makes the metric usable full-file.

Performance (RTX 5060 Ti, two 4K HEVC inputs via the ffmpeg libvmaf_cuda filter, vmaf + vmaf_neg models): adding all three features costs ~8% vs models-only. The extractors launch on their own CUDA stream and overlap with the model extractors' work instead of extending the shared picture stream's critical path; picture lifetime is handled by recording a consumed event after the last picture-reading kernel and making both picture streams wait on it, so the pool's existing finished-event reuse protocol transitively covers the own-stream reads. compute-sanitizer racecheck reports 0 hazards (run with per-frame host synchronization in place of the two-slot pipelining — racecheck cannot retire its tracking state without host syncs and runs out of memory on the pipelined variant; the cross-stream handshake under test is identical). The pipelined variant is additionally verified deterministic across repeated runs and bit-identical to the serialized implementation. One subtlety worth reviewer attention: the work streams are deliberately created CU_STREAM_DEFAULT (legacy-blocking) — producers like the ffmpeg filter fill device pictures with synchronous-API D2D copies that queue on the legacy NULL stream without blocking the host, and only blocking-flavor streams are implicitly ordered after NULL-stream work. With a non-blocking stream, ~4% of frames scored nondeterministically through the ffmpeg path; blocking flavor restores the ordering while still overlapping with the other extractors' created streams.

Supporting changes:

• New VMAF_FEATURE_EXTRACTOR_CUDA_CHROMA flag: the host→device picture upload (translate_picture_host) copied only the luma plane because all existing CUDA extractors are luma-only. The upload plane mask now widens to all planes only when a registered CUDA extractor declares it reads chroma — existing configurations upload exactly what they did before. The device→host direction (translate_picture_device) now downloads all planes unconditionally, since host pictures always carry every plane and CPU extractors that read chroma (psnr, ciede) expect them.
• All three extractors provide a flush that drains their async score callback, so the final frame's score is in the collector before scores are read after flushing the context.
• Tests: test_cuda_psnr_ssim_parity drives deterministic 8/10/12/16-bit YUV420P/YUV422P/YUV444P frames through the CPU and CUDA extractors via the public API. It asserts bit-exact PSNR, MSE, SSIM and L/C/S scores, compares APSNR aggregates, covers odd dimensions and automatic/explicit scales, and exercises the remaining scoring options. test_cuda_ciede_parity covers YUV420P and YUV422P in both 8-bit and high-bit-depth paths, asserts the 1e-3 tolerance, and checks the identical-frame +inf case. Both exit 77 (meson SKIP) when no CUDA device is available, so CI without a GPU reports them as skipped rather than silently passing. Dispatch assertions in test_feature_extractor.c are extended to the new extractors.

Naming follows the existing convention (vif_cuda/motion_cuda/adm_cuda): unique .name for --feature psnr_cuda / ffmpeg feature=name=psnr_cuda, with provided_features matching the CPU extractors so model-driven flag-aware selection works. The option tables mirror the CPU extractors' tables, following the existing CUDA extractors' pattern (they embed offsetof into each extractor's own state struct) — happy to factor the scoring math into a shared header instead if you'd prefer.

Notes:

• Rebased onto master at f85a8536. cuda: fix row stride in calculate_motion_score_kernel_16bpc (wrong scores for >8-bit input) #1552 has landed and its duplicate commit has been removed; this branch remains stacked on cuda: don't flush CUDA feature extractors twice when a thread pool is present #1553 for correct CUDA operation with a thread pool.
• While validating through ffmpeg's libvmaf_cuda filter I found that vf_libvmaf.c's copy_picture_data_cuda breaks out of its plane loop after plane 0, so chroma never reaches libvmaf and chroma-reading features report the psnr_max cap. That is an ffmpeg bug, not a libvmaf one (I patch it locally and plan to report it there), but it explains why chroma features through the filter need an ffmpeg fix to be useful.
• Possible follow-up (not in this PR): the model extractors (vif/adm/motion) still serialize on the shared picture streams; moving them to per-extractor streams with the same consumed-event handshake should overlap them the same way.

Tested on RTX 5060 Ti (sm_120), driver 595.71.05, CUDA 12.9/13.3.