Fix DirectInput data queries while GUI has focus

[HeresHavi]

Summary

Added a null check before the DirectInput proxy clears buffered event data.

Null-output event count and flush queries now return normally while the GUI owns input. Calls that provide an event array are still cleared so GTA does not receive input intended for the GUI.

Motivation

IDirectInputDevice8::GetDeviceData allows the output buffer to be null when checking how many events are waiting or flushing them. The proxy forwarded these valid calls, but then passed the null buffer to memset, causing an access violation.

For example, a client input integration might use a buffered keyboard and check how many events are waiting without copying them. If the player opens F8 or another MTA window at that moment, MTA owns the input and the old proxy path could crash the client.

GTA's default keyboard and mouse devices use immediate polling, so this requires a buffered DirectInput caller. The crash was reproduced inside MTA using a buffered keyboard created through the real DirectInput proxy.

Crash Stack

Exception: Access violation
Module: core_d.dll

memset
CProxyDirectInputDevice8::GetDeviceData
CProxyDirectInputDevice8::GetDeviceState

Test plan

Runtime

• Before Fix: A null-output query with one buffered keyboard event caused an access violation in memset.
• After Fix: The same query returned 0x00000000 with count=1, and the client stayed open.
• Valid Case: Queries with an output array were still cleared while the GUI owned input.
• Harness: Normal forwarding, null-output queries, and input suppression all passed.

Builds and Tests

• Debug | Win32: Client Core build passed, 304 client tests passed.
• Release | Win32: Client Core build passed, 304 client tests passed.
• Ran clang-format.

Checklist

• Your code should follow the coding guidelines.
• Smaller pull requests are easier to review. If your pull request is beefy, your pull request should be reviewable commit-by-commit.