feat: decode H.265 and AV1 with NVDEC on Linux

[devopvoid]

Summary

Stacked on #347 (hardware H.265 on Windows, which brings NVENC's H.265 to Linux as well), and based on its branch until that is merged.

The NVDEC decoders on Linux decoded H.264 and VP9. They now decode H.265 (Main profile) and AV1 (profile 0) too, where the GPU does (AV1 since Ampere):

• NvdecLibrary asks the driver (cuvidGetDecoderCaps) for H.265 and AV1 as it does for the others, and the factory offers what the GPU decodes: H.265 in the H265Format of feat: encode and decode H.265 in hardware on Windows #347, AV1 in profile 0.
• NVDEC's own parser takes the bitstream, so a codec is mostly a matter of telling it which. Its AV1 parser takes temporal units, which begin with a temporal delimiter OBU, and WebRTC's AV1 frames come without one, so one is put in front.
• Frames of AV1 spatial layers above the first go to dav1d, as those of VP9 go to libvpx.
• H.265 has no software decoder to fall back to: what NVDEC cannot decode is an error, and WebRTC asks the sender for a key frame.
• The Javadoc and the codec guide say so.

With NVENC's H.265 from #347, an NVIDIA GPU on Linux now carries H.265 calls both ways.

Testing

• The changed Linux sources (NVDEC, NVENC from feat: encode and decode H.265 in hardware on Windows #347, EncoderOutputProcessor, H265Format, the Linux factories) compile with GCC 12 in WSL (Debian 12), syntax-only against the WebRTC headers with the defines of the Linux build; the same check rejects a deliberately broken file. CI builds them for real.
• The existing tests cover it on a Linux machine with an NVIDIA GPU: hardwareDecodesH265 and hardwareCropsPaddedH265 (feat: encode and decode H.265 in hardware on Windows #347) with NVENC and NVDEC, and the AV1 decoder tests.

Not verified

Nothing here has run on an NVIDIA GPU under Linux: there is none here, and CI has no GPU, where the hardware tests skip. In particular whether NVDEC's AV1 parser needs the temporal delimiter, which is harmless if it does not.