[WIP] Web view geometry inheritance revisited.

I tried to bring the notion of different device screen option which allows you to render the page as though the webpage is visited from a particular screen sized device.

The motivation:
I've come across with a website which dynamically changes its content and hides some of information if the device is smaller than a desktop. QWebPage inherits screen geometry information from QWebView (which does the same from QWidget most probably). So far, the geometry run at default value (640x480 if i'm not wrong). This PR, make QWebPage to set geometry immediate after it is created, i didnt test the effect changing the geometry at runtime and what happens to QWebPage.

This PR brings a simple unit test which expects a screen width to be a default value. I added custom yield_fixtures, having thinking to run TestServer() with different settings object which should be carried down to the WebpageRender. Now, there is no way to write test which uses different settings/configuration unless defaults.py is physically changed on disk.

So, do you think, is there a need for small refactoring about about running server at different configuration or is it better to look for an update which allows you to change the geometry (device screen size) at runtime, based on a url parameter for example?
1. Can we allow to set custom geometry sizes? Why is it limited to a list of predefined sizes?
2. It seems that nothing prevents this option from being changed per-request. Is it correct? If so, the setting should set *default* display geometry, and there should be a render.html option for changing the size per-request. If you don't want to do it in the same PR it is fine, but `--display-profile` option should be renamed (`--default-display-profile`?).

By the way, what about dropping a command-line key and adding a way to change this per-request? :) Sorry for asking you to add this option and them asking to remove it. But other default values can't be changed at startup now, and it could be better to solve it consistently for all options. And if this option can be changed per request then tests don't need to start a custom server.