fix: mouse forwarding doesn't track legacy window reparenting - #55620

HWNDMessageHandler routes WM_MOUSELEAVE and WM_NCMOUSELEAVE to
OnMouseRange, so a leave the OS delivers to this window already reaches
ElectronDesktopWindowTreeHostWin::HandleMouseEvent, where kMouseExited
is filtered. Keeping the PreHandleMSG case as well skipped the
active_mouse_tracking_flags_ = 0 reset in
HandleMouseEventInternal, which left the cached flags set with the OS
tracking off; after that TrackMouseEvents() no longer arms anything for
the same flags.

With a single filter both paths behave the same, and the comments at the
filter and above RearmMouseLeaveTracking() describe what happens now.

Co-authored-by: Charles Kerr <charles@charleskerr.com>

Co-authored-by: LuoRain <luotianyi@luotianyi.me>

Chromium moves a live Chrome_RenderWidgetHostHWND with ::SetParent when
its WebContentsView changes window, which sends no WM_PARENTNOTIFY, so a
window that gains a view never hears about the HWND it now hosts, and
cannot filter the mouse leave that HWND reports once forwarding starts.

Load a view in one window, move it, still loaded, into a second window,
let real input hover an element while that window is still solid, then
enable forwarding over it. Check that moves keep being forwarded, hover
is never interrupted, and exactly one leave fires on exit.

Without the fix the first forwarded move is preceded by a spurious leave
and the element stops being hovered; with it the counts are 0 and 1.

Requested in review by @jkleinsc.

Co-authored-by: LuoRain <luotianyi@luotianyi.me>