Some Wayland compositors have support of fractional-scale-v1 protocol.
The protocol allows compositor to announce a preferred fractional scale
on a per-wl_surface basis. Qt forwards these Wayland events to an
application using a usual DevicePixelRatioChange event. However, in
contrast to the other platforms, this DevicePixelRatioChange event is
issued directly on widgets and not screens. Additionally, the exact
fractional scale is stored in QWindow object and not the current screen.
Note that in theory it is possible to obtain per-screen fractional
scaling on Wayland by interpolating data provided by wl_output and
xdg_output events but qtwayland does not do that.
If fractional-scale-v1 is not available, qtwayland will still fire
per-Widget DevicePixelRatioChange events, but, obviously, with the
per-screen possibly larger ceiled scaling.
This whole thing makes handling DPI changes on Wayland really simple.
All we need to do is to intercept DevicePixelRatioChange events firing
on QWindow objects and call the old device_pixel_ratio_changed handler
with the window's devicePixelRatio(). The only caveat here is not forget
to always set QWidget's parent before calling devicePixelRatio() on it.
When a QObject subclass (widgets, etc.) are provided a parent, then
ownership of that object is passed to the parent. Similarly, objects
added to a QLayout are owned by the layout.
Thus, do not store these objects in an OwnPtr.
This will help a lot with developing chromes for different UI frameworks
where we can see which helper classes and processes are really using Qt
vs just using it to get at helper data.
As a bonus, remove Qt dependency from WebDriver.
