To match other modules example directory structures we should deploy our
examples in a directory matching the module name, webengine and
webenginewidgets in our case.

qmake uses the relative directory of each example up to the upper "examples"
directory to decide where they will be deployed when running the sources
install target.

Change-Id: I59ce7ff8a30f98fad20064c7eecf72b784f1d275
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>

Import the sources as-is, without adding it to the build, to allow
performing diffs later on the changes that were needed to port it
to use QtWebEngine and manage source compatibility issues.

Change-Id: Icf8a284881ce2153e9b5a1ba97dbe77096f1b88d
Reviewed-by: Andras Becsi <andras.becsi@digia.com>

To allow QWebEnginePage to act on its own, let it own the WebContentsAdapter
and let the view delegate its calls through the page.

Change-Id: I851c753d068992e387edab0e1ea8018732af1fd7
Reviewed-by: Andras Becsi <andras.becsi@digia.com>

This is the first step toward re-implementing part of the QWebView
API on top of QtWebEngine. The plan is to import the complete headers
to facilitate diffs and progress tracking.

Changes squashed in this commit:
- Use the QWebEngine prefix for class names
- Strip out non-public members and directives
- Allow building using those headers by disabling the Q_PROPERTY
  macros and by adding a dummy implementation for virtual methods
  directly in the header
- Update the widgetsnanobrowser example to comply with the slight
  changes from the previous API

Change-Id: Ia7efa5430f775d09b493544430a04856cc7928f6
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>

Introduce a few more bits of our own very basic implementations
(URLRequestContextGetter and NetworkDelegate subclasses).

Still need to figure out the appropriate dependancies in blinq.gypi

We now have our own minimalistic subclass, which still makes use of
some shell parts.