winewayland.drv: part 4: First window contents on screen

The goal of this MR is to set up the minimum necessary infrastructure to display the contents of some simple, software rendered windows. This involves two major steps:

1. Associate a window with a Wayland surface and give it the xdg_toplevel role, so that the compositor can display it. We also have to implement the required initial xdg_surface configuration sequence to be able to safely (i.e., without the compositor disconnecting us with an error) attach buffers to the surface in step (2).

2. Implement the window_surface interface for the Wayland driver. For now we provide a simple (and suboptimal) window_surface_flush implementation: for each flush we create a new wl_shm buffer, copy the whole window contents (ignoring damaged bounds for now) into it and attach it to the target Wayland surface. In the next MR I will optimize this implementation in multiple ways: a. implement a buffer queue to avoid constantly allocating new buffers b. respect the damaged bounds of the window_surface to minimize copying of data from the window_surface to the SHM buffer (and also for correctness) c. communicate damaged surface regions to the compositor to (potentially) allow more efficient texture uploads.

With this MR many (software-rendered) applications can now display dynamic content on screen. We can't interact with the apps yet, but we do get to enjoy notepad in all its blinking-cursor glory.

Thanks!