perf: cut the processor time of hardware decoding on Windows

[devopvoid]

Stacked on #325 (which is on #323): the base is its branch, so the diff is these two commits only. Retarget to main once those are merged.

Hardware decoding in the media player saved little processor time on Windows, and at 4K cost more than software. Profiling the decoding thread (cycles per picture, QueryThreadCycleTime) showed why, and led to two changes.

1. Reuse the buffers of hardware-decoded frames. For every picture the hardware path dropped the system-memory frame it read the picture back into, and allocated a new I420 frame for the conversion: two fresh allocations of 12 MB per picture at 4K, and a fresh allocation costs more to fault in than the copy into it.

• The read-back frame now stays between pictures. It gets a new buffer when the picture size, the pixel format or the size of the decoder's surfaces changes. The last matters because the Direct3D 12 download copies the whole padded surface, where Direct3D 11 copies only the smaller of the two frames.
• The I420 frames come from a buffer pool. The conversion of other formats in software uses it too.
• Cycles on the decoding thread per picture: read-back 11.0 to 5.3 million at 4K and 3.3 to 1.8 at 1080p; conversion 10.4 to 5.7 and 2.2 to 1.3.

2. Direct3D 12 first on Windows. FFmpeg 8.1 has h264_d3d12va and vp9_d3d12va. The Windows build enables them and DeviceTypes() tries a Direct3D 12 device before Direct3D 11. A machine without Windows 10 2004 or a driver that decodes through Direct3D 12 goes on with Direct3D 11 as before. The component list changed, so the next Windows build rebuilds FFmpeg.

Process CPU per frame in the player on an NVIDIA GeForce RTX 3080, median of four runs of steady playback:

	software	Direct3D 11	Direct3D 12
1080p H.264	3.6 ms	4.2 ms	2.1 ms
4K H.264	6.6 ms	12.4 ms	5.4 ms

Direct3D 12 uses about 40% less than software at 1080p and 18% less at 4K, and about half of what Direct3D 11 does. The 7 to 8 times of the Apple M2 does not carry over. One machine, synthetic media and large run-to-run noise (the four runs of a setting differ by up to a factor of 2), so these are indications, not a promise; the guide says so and gives these figures.

The pictures are unchanged: all 67 tests of webrtc-java-media pass with webrtc.test.hardwareDecoding set, including the 1080p, 4K, 1366x768 and fallback cases of #325 that compare every frame with software decoding. A log line confirmed the Direct3D 12 device was the one created; it is not part of the change.

Not done:

• -Xcheck:jni on the media module.
• Other GPUs and Windows versions. The Windows ARM64 build is untested.
• --enable-d3d12va makes FFmpeg's configure fail where the Windows SDK has no d3d12video.h. The CI runners most likely have it, but I have not checked, so watch the Windows jobs.