[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] 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.
[Extensions] Check for conflicting entry points in the ModuleSystem

As we may have extensions coming from various processes, think that internal
extensions are run in the Browser Process and external extensions are run in
the Extension Process, the only point when we have all information of all the
extensions that would be run for a context is the module system.

So, if conflicting entry points are found, we log this as an warning and do
not register the extension.
Merge pull request #1040 from vcgomes/module-system-check-entry-points

[Extensions] Check for conflicting entry points in the ModuleSystem
Merge pull request #1083 from jeez/fix-segfault-crosswalk

[Extensions] Disable the Extension Framework entirely for --install and --uninstall
Build fix, kEnableOverlayScrollbars is not exported via CONTENTS_EXPORT

Define kEnableOverlayScrollbars ourselves.
Merge pull request #1084 from kenchris/overlaysb

Build fix, kEnableOverlayScrollbars is not exported via CONTENTS_EXPORT
Bump version to 3.31.32.0
Merge pull request #1067 from tmpsantos/raw_socket_common

[SysApps] Introduce SysApps foundations
Introduce OS_TIZEN and set specific settings for Tizen platforms

Introduce it to the build system.
Merge pull request #1093 from kenchris/settings

Introduce OS_TIZEN and set specific settings for Tizen platforms
[Extensions] Make RegisterExternalExtensionsInDirectory return a list of extensions name

Having XWalkExtensionServer::RegisterExternalExtensionsInDirectory returning
a vector of the loaded extensions name has proven to be useful for the XWalk
Extensions Shell. It is harmless for callers who doesn't need that information.
[Extensions] Add XESh: XWalk Extensions Shell

This commit adds a tool called XESh - a very simple Javascript
shell that loads external extensions for testing.

Usage: ./out/Release/xesh --external-extensions-path=$CODE/tizen-extensions-crosswalk/out/Default

After that you will get a prompt 'xesh>'. Just type any
javascript command or test your extensions.

What will be missing after this initial patch:
- centralize all shell 'handling' to a singleton and replace
fgets and fprintf calls to function calls of this class;

- make this shell handler use GNU readline so we get a better
shell for free :);

- Register the 'internal' native module;

- Make XESh rocks!
(a.k.a.: Any other shell cosmetics one feel like doing.)
[Extensions] Add a (simple) manual test for XESh

This manual test runs XESh passing an input file that
uses the echo extension. If the extension gets loaded then
it means the javascript command got executed and XESh has loaded
the echo extension properly.