This should be functionally no-op as the new state tracker has no side effect other than printing traces. It introduces a new pending/current states on the win data to track the requested changes, as well as the associated request serial for each of the property being changed.
Later, this tracker will help making the requests more asynchronous (removing the need for wait_for_withdrawn_state), avoid duplicate requests, and better decide whether the received updates are expected or should be applied back to the win32 window state:
- any update that is older than our last request, expected and matching our request, or unexpected but no-op can be ignored, - any update that wasn't requested or doesn't match the request (because the WM decided so) will need to be applied on the win32 state.
Tracking the current X11 window state separately will also allow us to later delay these updates on the win32 state, possibly by posting an internal message for win32u to call us back to get the necessary changes, when every other message has been processed and avoid calling SetWindowPos / syscommand directly from within the driver event handlers.