Switch to Xcb::Window geometry where it makes sense

There are a couple of reasons why it's worthwhile doing:

The first is that it makes the logic in the updateServerGeometry() function reusable for the interactive code path. As of now, when the window is being interactively resized, doInteractiveResizeSync() will issue some xcb_configure_window() calls but then it also implicitly assumes that updateServerGeometry() will call updateShape() and updateInputWindow() but skip m_frame.setGeometry() later. That is confusing, and error prone. For example, if somebody drops m_lastFrameGeometry in favor of m_frame.geometry() (which is an absolutely reasonable thing to do btw!!), a regression will be introduced: things would appear to work at first, but then eventually bug reports about input working weirdly would start piling up.

The second is hidpi scaling of wayland clients. toXNative(a + b + c) is not the same as toXNative(a) + toXNative(b) + toXNative(c). By switching to the device geometry, we leave less space for making an error.

The third is that lets us clean up some geometry manipulation code. When dealing with window hierarchies, it's more convenient to have m_window.position() rather than a dedicated property in the X11Window class such as wrapperPos().

cc #226