[Runtime] Add Crosswalk object to the Browser Process

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

This role is being fulfilled by different objects in Crosswalk,
including XWalkBrowserMainParts, XWalkContentBrowserClient,
RuntimeRegistry, RuntimeContext.

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.

Crosswalk object 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 Crosswalk object

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 Crosswalk
object instead of a XWalkContentBrowserClient. This is necessary because
some pieces of the client (including main parts) will depend on
Crosswalk object.

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 Crosswalk object

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

By looking at this patch, one could conclude that Crosswalk object might
end up becoming XWalkBrowserMainParts. This is a valid point, but the
reason to create a different object is as follow:

- Crosswalk object have the reverse relationship that XWalkBrowserMainParts
  have with XWalkContentBrowserClient.

- 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 Crosswalk object. Because the
first and second reasons, the separation still makes sense.