Fix asymmetric chroma plane stride handling in encoder preprocessing

[sprangerik]

When preprocessing incoming I420 source frames, WelsMoveMemoryWrapper
previously read only the U chroma plane stride (iStride[1]) and used it as a
shared stride for copying both the U and V chroma planes. If an incoming
frame has distinct, asymmetric strides for the U and V chroma planes (for
example, when the U plane stride is larger than the V plane stride), copying
the V plane using the U plane's stride advances the source pointer incorrectly.

This change ensures correct memory advancement for each chroma plane by:

• Modifying WelsMoveMemory_c to accept separate destination and source
  strides for the U and V chroma planes (iDstStrideU, iDstStrideV,
  iSrcStrideU, iSrcStrideV).
• Updating WelsMoveMemoryWrapper to read and pass iStride[1] and iStride[2]
  separately from the input SSourcePicture.
• Updating internal callers (DownsamplePadding and Padding) to pass their
  respective U and V line sizes cleanly.
• Adding a unit test (CustomChromaPlaneStrides) to verify that distinct,
  asymmetric chroma plane strides are handled correctly.