This slightly changes ime_ui_update_window to match what was previously
in winex11.drv, since e5f0cdfc, which
seems to be a more recent change.

Showing that they aren't sent to the focused window but only to the
INPUTCONTEXT hWnd member.

Despite the array size, these are considered to be "layered" for the purposes of
GL_FRAMEBUFFER_ATTACHMENT_LAYERED, and mixing array and non-array textures in
this way will trigger GL_FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49002

With the changes from 9008cd2f.

With the changes from ee7b5ebc.

Rename the musl functions to avoid compiler warnings about the
signature mismatch (double vs. long double).

With the changes from 2a5e68ab.

With the changes from 29c07324.

With the changes from df9c11ff.

These parts were supposed to contain a solid fill background without a border. If BorderSize is not
set, they will use the border size of 1 from the inherited progress class.

These parts only contain simple images that can be achieved with border fill backgrounds as well.
So visually, this change is a no-op. The reason for using image file backgrounds is that I tend
to use the same background type as the theme files for Windows. However, drawing border fill
background is much more efficient.

Pro Evolution Soccer 2008 demo is buggy and generates ~570,000 WM_PAINT messages for the progress
control. On Windows, it's ~1,140,000 WM_PAINT messages. DrawThemeBackground() on Wine is 10x more
expensive than that of Windows and I found little room for optimization. 60% of the time in
DrawThemeBackground() is spend for CreateCompatibleDC() and other 30% for actually drawing. So I
decided to change light.msstyles instead.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54728

Give the backend a more simple and self-consistent API.

This commit also changes behaviour, by virtue of *not* changing some frontends.
In specific, this commit does not modify the AVI splitter, which is known to
output top-down RGB samples on Windows if the original video uses them (this is
trivial to test by modifying test.avi in quartz to use "bgra" instead of
"yuv420p"). It also does not modify the Media Foundation color converter DMO,
whose tests imply that the MF_MT_DEFAULT_STRIDE attribute is always positive.

winegstreamer: Translate the MF_MT_DEFAULT_STRIDE attribute to flipped video in mf_media_type_to_wg_format().

The mf_media_type_from_wg_format function will use the video format to calculate stride.

To make it short: redirection has no impact on EnumProcessModules*()
behavior.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>