[Tizen] add the 'gst-plugins-atomisp-devel' buildrequires to spec.

chromium needs the header and lib files exported from this package to drive the
camera device on Tizen 2.1 hardware platforms.

BUG=#864
[Extensions] Convert 'entry_points' to be a vector of strings.

With this, we avoid potencial confusions and problems that could
arise about who owns the entry_points of an extension.
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.
[Android] Fix the incorrect context usage for HttpAuthDataBase.

The database file should be in the app's data directory. However,
if using the context of runtime lib package, Android doesn't allow
to create it. Fix it by using the application context which is for
the runtime client side.

BUG=#1002
[Android] Disable flaky tests in xwalk_core_test

The responsiveness tests seem to be failed randomly on buildbot. It might be
caused by the unstable status on testing phone since this test relies on a
timeout to wait for unresponsiveness in 40 seconds. However, there is no way
to ensure it would happen in 40 seconds so that the test can be passed. Locally,
there 2 tests can be passed.
[Extensions] Pass more data in EPH construction time

After changes to support multiple Extension Processes, we are creating
ExtensionProcessHost (EPH) right when RenderProcessHost is created, so
we can pass RPH directly to EPH. This simplify the logic of sending the
channel handle back.

We also pass the register extension path and send it right after the
process is launched, instead of creating a new task for this.

The members ep_rp_channel_handle_ and
is_extension_process_channel_ready_ are currently unnecessary but will
be helpful in follow up changes, so they remained.
Merge pull request #1009 from cmarcelo/clean-up-eph

[Extensions] Pass more data in EPH construction time
[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 #1010 from cmarcelo/rp-asks-for-channel-handle

[Extensions] Make RP synchronously ask for the extension channel handle
Merge pull request #911 from jchen10/camera

[Tizen] add the 'gst-plugins-atomisp-devel' buildrequires to spec.
Merge pull request #977 from vcgomes/entry-points-to-std-string

[Extensions] Convert 'entry_points' to be a vector of strings.
[Extensions] Adding Jesus to OWNERS
Merge pull request #1014 from cmarcelo/extensions-owners

[Extensions] Adding Jesus to OWNERS
[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.
Revert "[Extensions] Make RP synchronously ask for the extension channel handle"

This reverts commit fa7ae854e765bc01371162a1d51d17ee720dc12d.
It breaks page rendering for Android port.
Merge pull request #1008 from hmin/disable-flaky-test

[Android] Disable flaky tests in xwalk_core_test
Merge pull request #1005 from yongsheng/1002

[Android] Fix the incorrect context usage for HttpAuthDataBase.
Merge pull request #1016 from yongsheng/revert1010

Revert "[Extensions] Make RP synchronously ask for the extension channel...