[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.