Reland "RTCVideoEncoder: Enable initializing on the first frame"

This is a reland of commit a809473761a22244544d3375df44a1002b5c3567
The original CL performs the wrong downcast; webrtc::VideoFrameBuffer
is always downcast to blink::WebrtcVideoFrameAdapter. But it can be
other VideoFrameBuffer class, e.g., webrtc::I420Buffer.
This fixes the issue by adding the check that VideoFrameBuffer type
is kNative before casting.

Original change's description:
> RTCVideoEncoder: Enable initializing on the first frame
>
> RTCVideoEncoder initializes the encoder. VideoEncodeAccelerator needs
> to be configured the storage type of input VideoFrames.
> RTCVideoEncoder doesn't know the storage type of VideoFrame when
> InitEncode() is called. So we need to initialize the video encoder
> with SharedMemory and convert the GpuMemoryBuffer to SharedMemory in
> some cases, e.g, zero copy tab capture is enabled on Mac.
> This CL enables to initialize VideoEncodeAccelerator on the first
> Encode() call, in which RTCVideoEncoder knows the storage type of
> VideoFrame used in the encoding. The new delayed initialization is
> disabled by the feature by default.
>
> Bug: b:192106158, b:267966835, b:267995715
> Test: webrtc.RTCPeerConnection* on brya
> Change-Id: I2d131d52207c60309d4db7d8478370ebe000aebb
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4354849
> Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@chromium.org>
> Reviewed-by: Henrik Boström <hbos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1124172}

Bug: b:192106158, b:267966835, b:267995715
Change-Id: I4fe962cfb645a35297bf926974a96a5fd99fc51a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4387535
Reviewed-by: Henrik Boström <hbos@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1124697}