Video: Refactor `RenderMediaClient` to retrieve encoder profile synchronously

On some platforms, the cost of retrieving the VEA supported profile
is too high. For example, on Windows, the Media Foundation VEA's
call to `GetSupportedProfiles()` will approximately take 850
milliseconds and cause the GPU process's memory usage to increase
by 50MB. Due to this excessive overhead, we have no choice but to
switch to an on-demand and synchronous approach to get the VEA
configs.

As a result, when `MediaRecorder.isTypeSupported()` that
checks for a non-builtin codec is called or when a MediaRecorder
instance is created for the first time, there will be a synchronous
stutter of approximately 1 second in extreme cases (e.g. Windows).

Since we don't retrieve the profile immediately after starting the
render process, this CL can at least solve the current problem of
additional GPU process memory usage and cpu cost.

Meanwhile, this CL also changes how `media::IsEncoderSupportedVideoType()`
calls RenderClient delegate. The actual profile acquisition operation
of `RenderClient->IsEncoderSupportedVideoType()` is adjusted to be
executed based on the specific video type. In this way, it can be
ensured that when a codec is a built-in codec (e.g. vp8/vp9, h.264 &
av1 on non-android platform), the result can be directly returned
without having to make a blocking call to the function of
`RenderClient->IsEncoderSupportedVideoType()`.

Bug: 377100050
Bug: 40276507
Change-Id: Ib76e3b2a4c162a39b6d8db026b8f8dc8a55688f0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6151780
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Sida Zhu <zhusida@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#1405133}