Add myself to the AUTHORS file.
[XESh] Move all v8 related code to V8Runner.

This commit moves every v8 related code to V8Runner.
XWalkExtensionClient was also moved to XEShV8Runner because it
relates to a v8::Context (through XWalkModuleSystem). That cleans
up xesh_main.cc (hence, ExtensionManager), leaving
there only native-related pieces of the Extensions Framework.
[XESh] Move V8Runner to its own thread.

This patch fixes XESh so it can handle sync messages.
After some investigation we realized this bug was being
caused due to both native extensions code and their
JavaScript context being kept in the same thread.

BUG=https://crosswalk-project.org/jira/browse/XWALK-304
TEST=./xwalk/extensions/xesh/xesh_test.sh ./out/Release/
[Android] Implement the functions of application working from SD-Card.

  Crosswalk for Android port doesn't support the functions of application
moving to SD-card and working from SD-Card. This is because the AndroidManifest.xml
in xwalk app template doesn't support the application installation settings for
"preferExternal" or "Auto", and the corresponding intent actions should be registered
as response to the mounting and unmounting of SD-Card. This feature is to enable
the SD-Card related function supports.

BUG=https://crosswalk-project.org/jira/browse/XWALK-774
Merge pull request #1398 from zhang-qing/master

Add myself to the AUTHORS file.
Merge pull request #1446 from wang16/fullscreen_html5

[Android] Enable W3C fullscreen API support
Add screen.onorientationchange event listener

The function set is fired whenever the orientation changes.
The test has been updated to count how many times the orientation
has changed so far.

The entries have been changed as there are some unresolved bugs
with the ondemand loading making this not work otherwise.
Merge pull request #1460 from kenchris/onorientation

Add screen.onorientationchange event listener
Bump version to 4.32.69.0
Merge pull request #1451 from ShDavidliu/RunningFromSD

[Android] Implement the functions of application working from SD-Card.
[Android] Add adb_gdb_xwalk_runtime_client_embedded_shell for extension debugging

Xwalk extension is not attched to xwalk_core_shell, we needed to run xwalk_runtime_client_embedded_shell
to debug extension.
[Tizen] Register Application Extensions on Tizen.

Application Runtime Extension and Application Event Extension are not
registered on Tizen. This causes Runtime API and Event API don't work on
Tizen.

This PR fix the above issue.
Merge pull request #1465 from shaochangbin/register-module-tizen

[Tizen] Register Application Extensions on Tizen.
[Runtime] Add XWalkComponent

This interface will be used by XWalkRunner to manage the subsystems and
call them in convenient times. Looking at current code of Crosswalk, the
following points are relevant for most subsystems:

- Before the main loop starts, for setting up any objects and shared
  data.

- When a new RPH (most of the time Application) is started, to register
  extensions.

- After the main loop ends, and we are about to be destroyed, to
  shutdown the subsystem.

In some cases only one of those matter, for example, experimental/dialog
only cares about registering extension. The idea is that any other
important hook should be added to XWalkComponent. That way, XWalkRunner
will mostly care about calling all the components in the sequence,
instead of knowing details about each subsystem.

Keeping an ordered sequence (like the ScopedVector) also makes it easy
to destroy the components in the reverse order of creation. The name
component was choosen based on the concept of "browser components" from
Chromium browser.

In the long run we should follow their example and, when possible, add
self-contained separated features into directories structured like
src/xwalk/components/feature/{renderer,browser,common}. That will make
runtime/ more focused on the basic runtime.
[Runtime] Create a component for Application subsystem

Even though it is a "special" component (because Application concept is
central to Crosswalk), we can benefit from the XWalkComponent interface
for hiding the details of the subsystem.

In this and next patches we'll see sometimes a little bit of
"redundancy" between the old entry point and the new XWalkComponent
subclass for each subsystem. This is being done like this to reduce the
amount of change to make component system work.

In the long run, some modules may simply adopt the component class as
their entry point. For other modules, that don't depend on runtime/,
there'll still be a separate XWalkComponent subclass in runtime/ to glue
things up.
[Runtime] Create a component for SysApps

This class is the glue between the XWalkRunner and the
SysAppsManager. The sysapps/ directoy doesn't depend on runtime/, so the
glue code is used instead of making SysAppsManager implement
XWalkComponent.

By overriding the factory method the Android and Tizen can configure
which extensions they need to disable, instead of manually creating the
RawSockets extension.

In the case of Tizen, we create a component just for the currently used
implementation of DeviceCapabilities -- a newer one is being implemented
and will replace it when achieve feature parity.
Merge pull request #1413 from jeez/xesh-sync-fix

[XESh] Move all v8 related code to its own thread.
[Extensions] Fix xesh prompt

The InputWatcher is being told that it can read from input before we had
a chance to print the output from previous. Because we printed the
prompt at that moment, we ended up printing the next prompt before the
results.

With this change, we print the prompt only after the previous command
output is printed.
Merge pull request #1467 from cmarcelo/xesh-prompt

[Extensions] Fix xesh prompt
Merge pull request #1450 from cmarcelo/xwalk-component

[Runtime] Add XWalkComponent interface