[Runtime] Add XWalkRunner to the Browser Process

The role of this object if to own, setup and teardown all the subsystems
of Crosswalk in the Browser Process. It will serve as a central point
for those subsystems.

Currently, this role is being fulfilled by different objects in
Crosswalk, including XWalkBrowserMainParts, XWalkContentBrowserClient,
RuntimeRegistry, RuntimeContext. We'll step by step move things from
those objects to XWalkRunner.

Instead of using one of the Content API concepts as our central point,
the idea is to create a separated object with this clear role.

XWalkRunner is created by XWalkMainDelegate and destroyed by it. It's
lifetime is the execution of the program. It will be created only when
executing the Browser Process because CreateContentBrowserClient() is
called only in that process.

The factory function for construction and the virtual destructor are
preparation for allowing we have different implementations for different
platforms. The approach is the same as was applied in
XWalkBrowserMainParts.

The motivation for this changed was also described by Mikhail and
Alexander in
https://docs.google.com/a/intel.com/document/d/1N0VVlut7JCWFbAEwTQc0loN9_D2JlOXRJprQeCbXY2U
[Runtime] Move ownership of XWalkContentBrowserClient to XWalkRunner

This is mostly so we take control of BrowserMainParts, that has both
important hook points and currently own different subsystems.

Our browser test infrastructure was also changed to create a XWalkRunner
object instead of a XWalkContentBrowserClient. This is necessary because
some pieces of the client (including main parts) will depend on
XWalkRunner in the future.

XWalkBrowserMainPartsAndroid was duplicating the logic for creating
ContentBrowserClient, this commit removes the override because it
can use the base class implementation.

Embedded in this commit is a small cleanup: removed unnecessary
forwarding declarations and reset() calls to scoped pointers in
XWalkMainDelegate.
[Runtime] Move RuntimeContext creation to XWalkRuntime

This patch exposes to XWalkRuntime the two main stages of initialization
of the Browser Process and moves creation of RuntimeContext to it.

By looking at this patch, one could conclude that XWalkRunner might end
up becoming XWalkBrowserMainParts. This is a valid point, but there are
some reasons to create a different object:

- XWalkRunner have the reverse relationship that XWalkBrowserMainParts
  have with XWalkContentBrowserClient. XWalkRunner creates/owns the
  XWalkContentBrowserClient (and any other Content API client object for
  Browser Process).

- BrowserMainParts ends up being owned by the framework. While it's
  scope might fit our case, it is not as clear as the approach of having
  a separated object.

- A minor reason: it is easier to fill the new entity iteratively
  instead of moving all the XWalkBrowserMainParts content at the same
  time. Gives us opportunity to review some object ownership decisions.

It's possible that in the future XWalkBrowserMainParts gets reduced to
just forwarding the important hooks to XWalkRunner. Because the first
and second reasons, the separation still makes sense.