This also fixes the indent on top and bottom for the collection view.

Rather than the windows ARRAYSIZE() which ends up as sizeof(*RtlpNumberOf(A))
mostly for C++.

In external rendering these fields should never be used.

refs broken #22228

that really can't work due to empty segments
and be fixed without big changes

pretty useless since we can no longer change it...

In that case we don't call CommonInit.

We also check that on Winstore the legacy "winrt-d3dcontext" variable is set if
an external callback is not used.

During fast resizing we might get a lot of WM_SIZE messages which are each
sending a CHANGE_DISPLAY_SIZE which may take time to get to the display thread.
We bypass a part of this lag by reading directly the current size of our parent
HWND (since we always place our HWND at 0,0 with the full size).

This is similar to what we have before when we handled all the HWND in this
part of the code. We read the window size directly on each size change.

The dimension to use is always set in area->vdcfg.display. The hwnd size always
matches this size since we resize it accordingly for each
DISPLAY_CHANGE_DISPLAY_SIZE call.

There is a slight delay between the moment the window tells the core of the
size change and the moment it's effective in the display. So resizing quickly
is not as smooth as when reading the HWND size directly.

Implement the TODO: call a DISPLAY_CHANGE_DISPLAY_SIZE when we detect the
external swapchain dimensions have changed.

We don't need a special callback to read the "display" dimensions.

At some point this code should go away.

area->vdcfg is always set to the display size received from the core.

When rendering to NV12/P010 otherwise we only need one.

We don't need to know anything about the display module in Common code. Only
the Init needs to keep track of the source video format.

So we don't have to pass the display module at each UpdateRects nor the source
video_format_t. It may also change if the texture is bigger than the decoded
size (D3D11 extra padding).

They always cover the same (window) area so there's no reason to use two.

We do not need to know the first placement of the video window. It's always
shown (black) from the start now.

It is always true now that all modules have been fixed to properly place the
textures.

We will never copy more than the visible area (plus one if the source is an
odd dimension).

We cannot rely on the output always having the exact aspect ratio of the video.
So we draw on the whole window area and place the video accordingly.

Right now all Windows display module render on the hvideownd which is already
cropped and positioned according to the PlacePicture results.
In external rendering we do not have this mechanism and so we need to be able
to render on the full display but cropping according to the PlacePicture result.

Ultimately that should be the only mode. D3D and OpenGL should have no problem
cropping and stretching in the proper area. WinGDI should also be able to only
draw on a portion of a HWND. It can already stretch.