tweak(gui): Animate GUI window moves fluently on high render frame rates

[bobtista]

• Follow up for tweak(gui): Decouple GUI window-move animations from the render frame rate #2833

#2833 decoupled GUI window-move animations from the render frame rate, but
AnimateWindowManager still accumulates fractional base-rate time and advances the
animations only in whole steps. Window positions therefore change about 30 times per
second even when the game renders faster.

Now the manager passes fractional base-frame deltas to the movement processors, animated
positions keep subpixel precision, and coordinates are rounded only when applied to a
GameWindow. The subpixel precision is required because velocity clamps to
1 pixel per base frame near the rest position, which is 0.25 pixel per render frame at
120 fps and truncates to no movement at all with the previous integer position. Velocity
ratios are adjusted for the fractional delta with powf, which keeps the duration
approximately constant across frame rates rather than exactly equal, since the position
is still integrated once per render frame.

Every completion path now applies its terminal position. SlideFromRight, SlideFromLeft
and SlideFromRightFast marked the animation finished without ever writing the end
position, leaving the window short of its rest position by up to one update of travel.

On the in-game control bar, movement increased from 24 position updates in 744 ms at
30 fps to 85 updates in 736 ms at 120 fps.

ProcessAnimateWindow.cpp is shared Core code compiled into both games, so the Generals
manager and header change with it.

This only affects client-side GUI state and does not touch game logic, replays, or CRC
calculations.

Todo:

• Measure the Zero Hour control-bar animation at 30 and 120 render fps
• [s] Replicate to generals