On Windows, improve the performance for high polling rate mouse.

[benkyoujouzu]

When using a high polling rate mouse on Windows, fast mouse motions result in numerous WM_NCHITTEST messages being generated. Processing each of these messages via DefWindowProc leads to noticeable frame rate drops across various applications (bevyengine/bevy#12679).

Given that winit doesn't utilize the return value from DefWindowProc for WM_NCHITTEST, we can bypass invoking DefWindowsProc for this message, thereby substantially boosting performance for high polling rate mice.

Edit: This breaks some behaviours like mouse capture. Additional fixes needed.

• Tested on all platforms changed
• Added an entry to the changelog module if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality
• Updated feature matrix, if new features were added or implemented

[benkyoujouzu]

It appears that the frame rate drop isn't caused by DefWindowProcW on WM_NCHITTEST, but rather by a non-zero return value of public_window_callback on the WM_NCHITTEST message. To illustrate, consider the following handling of WM_NCHITTEST in public_window_callback_inner, which also resolves the frame rate drop issue:

        WM_NCHITTEST => {
            let _ = unsafe { DefWindowProcW(window, msg, wparam, lparam) };
            result = ProcResult::Value(0);
        }

However, I'm uncertain about how the return value of public_window_callback is processed. Can someone help me with this?