[Runtime] Polish application browser test

1. Add a new xwalk.app.test.notifyTimeout API to notify test timeout.

2. Make test API extension running on UI thread. And let the client to return
the xwalk.app.test.notifyPass/Fail/Timeout callback explicitly when it's ready.

3. Using Promise to provide a common asynchronous test driver. The JS can now
write code like below to test:
  function test1(resolve) { ... } // calls resolve() when test is done
  function test2(resolve) { ... } // calls resolve() when test is done
  var tests = [test1, test2];
  xwalk.app.test.runTests(tests, 5000); // if all tests can't finish in 5
  seconds then a TIMEOUT notification will be sent.
[DBus] Create DBusManager in ApplicationSystemLinux

ApplicationSystemLinux manages lifecycle of DBusManager and provides
accessor method, so that other parts of the system can use it.
Merge pull request #1340 from seanlong/event_router

[Runtime] Polish application browser test
Bump version to 4.32.57.0
[Applications][Linux] Remove unused variables from xwalkctl
[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.
[Applications][Tizen] Fix having to export the HOME variable for user 'app'

When the user changes to the 'app' user (e.g. using 'su - app') the
HOME environment variable is not set by default, this variable is used
for finding the address of the D-Bus session bus.

This is separated in a different header so it can be used by other tools,
see later commits.
[Applications][Linux] Add a tool to launch applications

This tool will launch an Application using its AppID (either via
parameter or via argv[0]).  It will talk to Crosswalk using the
'org.crosswalkproject.Running.Manager' and
org.crosswalkproject.Running.Application' to run and follow the
Application lifetime.

On Tizen, this tool will use the appcode infrastructure to get more
information about the launched application state.

We re-use the functionality of setting the 'HOME' environment
variable that was introduced in the previous commit.

And to avoid polluting the main binary with #ifdef's we put
the platform specific code (dealing with Tizen's appcore) into
a separated header.
[Extensions] Avoid running CrashExtensionTest when --disable-extension-process is set.

Using the ExtensionProcess is mandatory for this test, so we avoid running it.
Merge pull request #1358 from cmarcelo/xwalk-runner

[Runtime] Add XWalkRunner
[Android] Refine the URI scheme Job Factory usage

Mark the Job Factory usage more clearly with three steps:
    1, Add default schemes(http, ftp etc)
    2, Add new basic schemes(data, file, app)
    3, Add scheme interceptors(content, file asset)

Use a custom URLRequestJobFactoryImpl to support navigation
interception and URLRequestJob interception for navigations to
url with unsupported schemes.

Add the request interceptor to handle the shouldInterceptRequest
API for embedder.

BUG=https://crosswalk-project.org/jira/browse/XWALK-655
[SysApps] Add a stub for the Device Capabilities API

This patch adds the basic bits for starting the development of the
Device Capabilties API:

- The IDL files to generate the data serializers.
- The JavaScript shim file, initializing the internal extension system
- An Extension class and an Instance class.
- Register the extension on the XWalkBrowserMainParts (only desktop ATM).
[SysApps] Add an data provider abstraction for the CPU information

The data provider will access the underlying platform and fill a SystemCPU
struct. We are using Chromium classes to retrieve this information, which is
platform independent. In the following patch we will be adding a platform
specialization for querying the CPU load.

Note that the SystemCPU struct is not defined anywhere. By adding SystemCPU dictionary
interface to the IDL file, we instruct the generators to generate the header and
code for this struct, also a function to serialize the struct as a message we can send to
the JavaScript shim.
[SysApps] Add platform dependent CPU info providers

The buildsystem will handle the compilation units accordly to the suffix. No
compile time guards (#ifdefs) are necessary here.

The Windows implementation is just a no-op stub.
[SysApps] Add the Device Capabilities Object

Usually, we could be handling static methods at the Instance object, but this
API requires an EventTarget (coming soon) which adds a bit of complexity,
that's why we need an Device Capabilities Object.

DeviceCapabilitiesInstance has now a BindingObjectStore, which is a class for
keeping track of BindingObjects lifecycle and routing messages. It will
automatically destroy BindingObjects when they are no longer used and route
messages to objects based on the unique ID.

In the JavaScript side we have:

common.BindingObject.call(this, object_id) will initialize the BindingObject
and stablish the "link" for routing the messages.

DeviceCapabilities  is being exported at the root of the API namespace and cannot
be created with "new". We have only on instance of this object per app.
[SysApps] Hook the CPUInfoProvider into SysAppsManager

SysAppsManager will also centralize the creation of data providers. We might
create a new class just for that in the future if there is enough demand.
[SysApps] Implement the Device Capabilities getCPUInfo()

We first add an callback and function to the IDL to make it generate the Promise
reply serializers, which contains the SystemCPU + error message if applicable.

A function handler for "getCPUInfo" is also needed and it will associate the
message coming from the extension with a class method. It is being registered in
the Instance constructor.

GetCPUInfo::Results::Create is generated from the IDL. This function will
create a message which the promise wrapper will receive.

info->PostResult() has internally the callback ID that maps to a callback ID in
the JavaScript shim, so the message will reach the correct recipient.

In the JavaScript shim, is important to use "this_.addMethodWithPromise" so it will
wrap the Binding Object routing ID automatically to the message and associate it
to the Promise.
[SysApps] Add CPUInfoProvider unit tests

The test basically pings each entry point of the API and check if
the returns values are within a sane range.