feat: build WebRTC with H.265

[devopvoid]

Summary

WebRTC was built without H.265 (rtc_use_h265 follows proprietary_codecs, which is off), so a call could not carry H.265 even with an encoder and decoder for it: there was no H.265 RTP packetization, no depacketizer (WebRTC creates none and drops the stream) and no H.265 negotiation. This builds WebRTC with it. It is the groundwork for hardware H.265 in calls on Windows, macOS and Linux, which the hardware codec factories add next.

• rtc_use_h265=true in the GN args, and RTC_ENABLE_H265 for the JNI code, so that it is compiled against the same declarations. None of the headers the JNI code includes changes a struct layout with it.
• WebRTC has no H.265 encoder or decoder of its own, and none is added: H.265 is offered only by a factory that brings one (a Java one now, the hardware factories later). HEVC stays hardware only, as in the media player.
• A compiled WebRTC is used only if it was built with the current GN args. The args are recorded next to the library, in the build tree and in the install directory, and a build without the record, or with other args, is built again; the stale installed library is removed first so that nothing links it meanwhile. Before, any existing webrtc.lib/libwebrtc.a was taken as it was, so a change to the args never reached a machine that had built WebRTC once. The record is written only when gn and ninja succeed. CI's WebRTC cache key already hashes this CMakeLists.txt, so CI rebuilds on its own.
• VideoEncoderWrapper (Java encoders) parses the QP of H.265 frames and uses the H.264 quality-scaling thresholds for H.265, as WebRTC's own Android wrapper does (bugs.webrtc.org/13485).
• The codec guide and the Javadoc describe H.265.

Testing

• Windows x64: with the GN args changed, the configure step found no record, removed the installed library, synced and rebuilt WebRTC (only what rtc_use_h265 touches is recompiled; about 5 minutes here). The new library has the H.265 packetizer, depacketizer and bitstream parser, and the next configure reuses it.
• VideoCodecFactoryTests.h265CallRoundTrips is new: a call between two local peer connections negotiates H.265 through a Java encoder and decoder, which wrap the test payload in H.265 NAL units (VPS, SPS, PPS and an IDR slice). Every frame received is one that was sent. Without H.265 in WebRTC the receiver has no depacketizer for the stream and nothing arrives.
• The full test suites of webrtc and webrtc-java-media pass against the rebuilt library.

Not verified

The rebuild ran on Windows x64 only; CI rebuilds WebRTC for the other six platforms. No real H.265 encoder or decoder is involved yet: the test checks negotiation, packetization and depacketization with a synthetic bitstream.