[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.
[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] 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.
squash
[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.
squash
[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.
squash
MakeCreateJSModuleFromResourcePublic
native_module
browsertest
[SysApps] Add Raw Sockets stub

Just the skeleton to serve as base for the interfaces implementation. No API is
currently exposed.
[SysApps] Add the TCPSocket implementation

This is the initial implementation of the W3C's Raw Sockets TCPSocket interface.
It is not complete but is fully functional. Some issues with the spec are being
worked with the standardization body, like the fact that the send() method is
technically sync (although we implement as async always returning true).

A notable missing feature is the throwing of exceptions on invalid parameters,
but the error callback is still called under these circumstances.

We also add the RawSocketObject class. This class is going to concentrate all
the shared code among the different interfaces of the Raw Socket API. Currently only
the ReadyState is shared.
[SysApps] Make it possible to create a TCPSocket from a connected socket

The TCPServerSocket will need to create a TCPSocket from incoming connections.
This patch makes it possible to create an object in the native side first and
handle the identifier to the JavaScript context.
[SysApps] Add TCPServerSocket implementation

Added an incomplete but functional implementation of the
Raw Sockets TCPServerSocket interface.