parse_xpk: Define HandleError() and its constants before using them.

The existing code to warn the user if the Python crypto modules were not
installed was simply not working, as HandleError() and
EXIT_CODE_CRYPTO_NOT_FOUND need to be defined before the former is called.
[Windows] Fix runtime is using wrong content_app target

On Windows, upstream is trying to provide alternative to split
chrome.dll into several parts. Therefore, target content_app
is now content_app_browser, content_app_child, content_app_both.
It's not relevant with xwalk, xwalk should use content_app_both
to obtain all it need for content app.
[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] Add a test that another extension depends on another

In this test an extension ("another") depends on two other extensions ("outer"
and "outer.inner"), by using objects that are provided by those extensions.
[Mac] Fix the build

[chromium-style] virtual methods with non-empty bodies shouldn't be declared inline.
[chromium-style] Complex constructor has an inlined body.
[chromium-style] Complex class/struct needs an explicit out-of-line destructor.
[chromium-style] virtual methods with non-empty bodies shouldn't be declared inline.

http://www.chromium.org/developers/coding-style/chromium-style-checker-errors
Merge pull request #994 from rakuco/py-use-before-definition

parse_xpk: Define HandleError() and its constants before using them.
[Android] Fix ExtensionBroadcast test

With load on demand enabled (the default now) instances are only created when
needed. This test is failing because it assumes that a new Extension instance
is created for the iframe, and as the code running in the iframe doesn't need
the any instances they are not created.

This fixes substitutes the assumption that the instance will be created, when
the context is created by explicitly calling the extension.

With this assumption fixed, the test can be enabled back.

BUG=#984
[Extensions] Pass to RP whether we use or not use extension process
Merge pull request #1024 from cmarcelo/let-rp-know-whether-ep-is-enabled

[Extensions] Pass to RP whether we use or not use extension process
[Extensions] Register external extensions when EP is disabled

Fix the bug of external extensions not working when
--disable-external-process flag was passed. This is the default behavior
for Android. The problem was that we were sending the extensions to RP
before adding the external ones.
Merge pull request #993 from vcgomes/nested-load-on-demand-test

[Extensions] Add a test that another extension depends on another
Merge pull request #1026 from cmarcelo/fix-disable-extension-process

[Extensions] Register external extensions when EP is disabled
Merge pull request #1013 from vcgomes/fix-android-test-with-load-on-demand

[Android] Fix ExtensionBroadcast test
[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.
Merge pull request #1022 from poussa/mac-compile-8

[Mac] Fix the build
[Android] Remove duplicated asset files for Android tests.

There are 3 instrumentation tests for different purposes. They use
some common files. However, currently these files are copied in
many places. This fix is to share all of these asset files in a
shared folder: test/android/data. If a test APK needs them, copy
them in the generated output folder.

This is the first step: share asset files. Next step is to share
Java code.

BUG=https://crosswalk-project.org/jira/browse/XWALK-95
Revert "[Tizen] add the 'gst-plugins-atomisp-devel' buildrequires to spec."

This reverts commit cd8ac2dbb7fa164cf20118bdcbfdc011e81602a8.

The original commit breaks xwalk-tizen build since currently its dependency
upon 'gst-plugins-atomisp-devel' package can't be fulfiled by tizen.org repo.
Merge pull request #1031 from jchen10/camera

Revert "[Tizen] add the 'gst-plugins-atomisp-devel' buildrequires to spe...
Merge pull request #1020 from yongsheng/refactortest

[Android] Remove duplicated asset files for Android tests.
[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