Don't call the IPCWindowProcHandler.

As we only use in-process plugins, so this is not needed.

Fixes issues with InSendMessageEx, which merely tells us if there is an
inter-thread message waiting anywhere, but it can be sent to any other
window or even be a different message sent to the current window. It's
possible to SendMessage during processing of an inter-thread message without
impacting InSendMessageEx's results (because it's badly designed), so Gecko
would call ReplyMessage on an intra-thread message, messing up a totally
unrelated message.

FFXIV Launcher does something like this when it has not enough disk space
and displays a message box for it. The thread that calculates the disk space
sends a user message to the main thread, and ends up blocking. Immediately
after sending it, it posts a WM_CLOSE, but since it's blocked, it should wait
until the main thread finishes processing the message (when the message box
is closed). However, creating the message box results in a WM_KILLFOCUS being
sent to the Gecko window. This is an intra-thread message, but since there's
the prior user message that blocks the other thread, InSendMessageEx returns
that it is indeed waiting, causing ReplyMessage to be called in response to
this intra-thread WM_KILLFOCUS, which is wrong and instantly quits the app
(because of the WM_CLOSE).

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

widget/windows/nsWindow.cpp

@@ -4599,7 +4599,9 @@ LRESULT CALLBACK nsWindow::WindowProcInternal(HWND hWnd, UINT msg, WPARAM wParam
   if (!targetWindow->mInDtor)
     kungFuDeathGrip = targetWindow;
 
+#ifndef WINE_GECKO_SRC
   targetWindow->IPCWindowProcHandler(msg, wParam, lParam);
+#endif
 
   // Create this here so that we store the last rolled up popup until after
   // the event has been processed.