[Extensions] Use type-safe functions to fill the replies

When using delayed replies for IPC messages, we can hold the
IPC::Message* with the reply and fill it with values later, before
sending.

We used the more general function IPC::WriteParam, but one drawback is
that it doesn't do any type checking. Message macros / templates already
generate proper functions that will do the necessarily checking, so we
can call the appropriate WriteReplyParams() of the message we are
replying.

In XWalkExtensionServer because ListValue doesn't have a copy
constructor, we construct the typed reply param ourselves and write
it. It is more verbose but also type-safe.
[Extensions] Make RP synchronously ask for the extension channel handle

There are situations in which Render Process (RP) gets a navigation
request before it has all the information from the Extension
Process (EP).

Currently we don't enforce any ordering, EP is created, tells Browser
Process (BP) about the new channel handle created for EP<->RP
communication and BP sends this handle to the RP. Before all this
happens, a navigation may occur and a new v8::Context is created without
all the JS code for extensions in EP.

The new code changes so that RP asks BP (synchronously, to ensure
ordering) for the channel handle. This message is handled by
XWalkExtensionProcessHost using a delayed reply handler, allowing it to
launch the process and wait for the channel creation before replying.

Note that in EP we change the order of the channel creation, we first
load the extensions and only then register the channel. This guarantees
that when RP connects to the channel, EP will have everything ready.

This patch should fix the cases at hand -- because we enqueue the
"register extensions" message in the channel and RP process it before
navigations.

To ensure this works regardless implementation details of the IPC, a
follow up change will be necessary: make the XWalkExtensionClient
ask (synchronously, to ensure ordering) for the extensions, instead
waiting for it to be sent from the XWalkExtensionServer. With hindsight
this makes completely sense.
[Android] Update packaging tool and parsing tool to support extended manifest fields.

1  These changes are used to support the parsing and packaging of the extended
   manifest fields including launch_path, application version, description and
   permissions based on current manifest specification.
2  In the packaging tool and parsing tool, the parsing and packaging process are
   added for the following fields: launch_path, application version, application
   description and permissions(geolocation). both the manifest json file paring
   and the command-line method parsing and packaging processes are extended for
   these fields. For the field of description, the /path/to/res/values/strings.xml
   and the corresponding field in /path/to/AndroidManifest.xml are associatively
   processed.
3  Add the corresponding test cases for the fields.

BUG=#1017, #768
[Android] Implement loading app from manifest file.

When the Java method AppFromManifest() in Java class XWalkView is
called, the manifest string will be passed to c++ side, it will be
parsed by the manifest parser. If a valid target URL could be got,
it will be passed back to the Java side, the Java class XWalkContent
will navigate to target page with the URL.

To comunicate between C++ and Java, the following interfaces are
added to XWalkContent.java:
1. The native method nativeSetManifest().
2. The Java method onGetUrlFromManifest() called by native.

BUG=#621
[WiDi API] [RE] First commit for Presentation API implementation on Android

RECOMMIT it to add backward compatibility support for Android 4.x device.

NOTE: Since the current implementation relies on the DisplayManager
class introduced from Android 4.2 (API Level 17), as a result, the
Presentation API is only available on Android 4.2+, but won't break
running on the older version.

This commit is the first patch to implement Presentation API spec on
Android. It is intended to bring wireless display support into Web. The
new API is placed under 'navigator.presentation' namespace, and the
'displayavailable' property and its change event is implemented in this
commit by use of DisplayManager in Android SDK.

SPEC=http://otcshare.github.io/presentation-spec/index.html
BUG=https://github.com/crosswalk-project/crosswalk/issues/577
[Android] Add test case for loadAppFromManifest().

This patch contains the test case about loadAppFromManifest on
embedded and shared mode.
Invoke loadAppFromManifest on main thread, then get the title
and compare the two titles.

For embedded client test:
1. install XWalkRuntimeClientEmbeddedShell.apk
2. python build/android/test_runner.py instrumentation \
--test-apk=XWalkRuntimeClientEmbeddedTest -v -f \
testLoadAppFromManifest

For shared client test:
1. install XWalkRuntimeLib.apk
2. install XWalkRuntimeClientShell.apk
3. python build/android/test_runner.py instrumentation \
--test-apk=XWalkRuntimeClientTest -v -f testLoadAppFromManifest
Merge pull request #981 from ShDavidliu/manifest

[Android] Update packaging tool and parsing tool to support extended man...
Merge pull request #1034 from tmpsantos/create_module_from_resource

[Extensions] Make CreateJSModuleFromResource public
Merge pull request #1027 from cmarcelo/rp-ask-for-channel-handle-take-2

[Extensions] Make RP synchronously ask for the extension channel handle
Merge pull request #972 from gaochun/load_app_from_manifiest

[Android] Implement loading app from manifest file.
Merge pull request #1028 from hmin/widi-android-part1

[WiDi API] [RE] First commit for Presentation API implementation on Andr...
[Extensions] Avoid race condition in Extensions registering.

This patch inverts the registration order. Now during the Client's
initialization we synchronously ask the Server for the extensions
to register.
Merge pull request #1015 from cmarcelo/better-reply-write

[Extensions] Use type-safe functions to fill the replies
Merge pull request #1012 from jeez/fix-race-register-extensions

[Extensions] Avoid race condition in Extensions registering
[Extensions] Add support for persistent callback listener

This is going to be the base of the EventTarget implementation. It is
important to remove the listener at some point otherwise the object will
leak.
[Extensions] Add browsertests for the persistent callback listener

The test implements a heartbeat which works in a similar way of an EventTarget.
The callback is set only one and gets called multiple times.
[SysApps] Add the convenience classes and prototypes

These C++ classes and JavaScript prototypes are helpers for the common
places that appear all around the SysApps APIs specifications.

The main features are:

- Helpers for creating objects managed by the extension.
- Easy way of declaring API methods.
- EventTarget implementation, and thus, helpers for dealing with
  events.

For more information, check the documentation on the code.
[SysApps] Make the common API availiable as a module

Make it available to be accessed via requireModule(). It is going
to be used by the SysApps APIs like Raw Socket.
[SysApps] Add unit tests for the convinience classes
[SysApps] Add browser tests for the common JavaScript API

These tests are testing the functionality of the helper JavaScript
prototypes and objects, like the EventTarget.