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.
Merge pull request #1060 from jeez/xesh

[Extensions] Add XESh: XWalk Extensions Shell
[Extensions] Add an ExtensionServer to the Browser Thread

Currently for the in-process extensions, there is a separated thread
for running the extensions. This patch adds an ExtensionServer to the
existing Browser Thread, which will allow extensions that interacts with
the UI or are limited because of main loop integration to run on the main
thread.
[Extensions] Make it possible to query an ExtensionServer for an extension

This function will be used to decide on which thread the extension has
to be created.
[Extensions] Route messages to the appropriated server

Based on the extension name and the extension ID, we route the messages
to the appropriated ExtensionServer running on the Extension thread or the
Browser thread.

On the in-process extensions, 2 messages that are normally directed to the
ExtensionServer on the Extension Process are now completely handled by the
filter. One example is the GetExtensions message that has to combine a list
of available extensions from two different servers in a single reply.
[Extensions] Run external extensions on the Browser Thread when single process

When using the single process mode, external extensions will run on the UI
process by default. This is more compatible with the multi process mode where
the external extensions are running in the main thread of the Extension Process.
[Extensions] Run tests on the Browser Thread by default

But keep hooks for running tests on the Extension Thread if need. Extensions
requiring IO main loop will need that.
[Extensions] Add browser tests for in-process extension threads

This test verifies if extensions registered to the Browser Thread are
indeed running on the Browser Thread. The same applies for extensions
registered to the Extension Thread.

We also test if messages (sync and async) are working on both scenarios.