[Android] Support shared library mode for XWalkRuntime when using WindowAndroid.

XWalkRuntime in shared mode requires WindowAndroid to have a share library context
to get resources in shared library.  Use the library context to construct WindowAndroid
in XWalkView.

BUG=https://github.com/crosswalk-project/crosswalk/issues/678 , 666
[Android] Implement runtime client with runtime library embedded

We should support both shared and embedded mode for runtime
client to use runtime library, which providing java class, native
lib and pak resources for runtime client.

Currently, only shared mode is implemented. In shared mode,
runtime library is an Android app.

This commit implements an alternative to allow packing runtime lib
embedded in runtime client. The api will stay unchanged and the
client of runtimeView will not aware the difference.

Add a new target, xwalk_runtime_client_embedded_shell, which is
the shell using runtime view with library embeded. It's for
testing purpose.

TODO=https://github.com/crosswalk-project/crosswalk/issues/657
BUG=https://github.com/crosswalk-project/crosswalk/issues/640
[Android] Fork the target for sample app from app template

Sample application should not share the same code with
application template for web developer.
We might want to demonstrate some xwalk's feature in
sample but not in app template.

BUG=https://github.com/crosswalk-project/crosswalk/issues/725
[Android] Implement APIs for external extensions

Similar to native extensions system, we need to allow web developers
or others to write their own extensions. Due to the shared mode, there
are some client classes in runtime client side which are used by
external extensions.

1. XWalkExtensionClient: the base class for external extensions.
2. XWalkExtensionContextClient: the context to be used by extensions to
help get the context.
3. Configuration system: define a configuration system to specify what
kind of extensions to be loaded and created by crosswalk.

So for web developers, an external extension is implemented with below steps:
1. Write the JavaScript code stub same as the native extension system.
2. A new class inherited from XWalkExtensionClient implements the methods
used by JavaScript.
3. Configure the extension in extensions-config.json which should be packaged
in android asset, like:
[
 {
   "name": "myextension",
   "class": "com.example.MyExtension",
   "js_api": "myextension.js"
 }
}

Developers don't have to create and register their extensions. Instead,
crosswalk runtime will load and create them according to the configuration
system.

Next is to add one test case for external extension mechanism.
Merge pull request #751 from wang16/roll_deps

Bump chromium-crosswalk in DEPS.xwalk.
Merge pull request #708 from yongsheng/external-extension

[Android] Implement APIs for external extensions
Merge pull request #724 from sqliu/otcshare-support-share-in-window

[Android] Support shared library mode for XWalkRuntime when using Window...
Merge pull request #731 from wang16/app_demo

[Android] Fork the target for demo from app template
[Android] Pack the files needed by app template for embedded mode

To create an app using embed mode of runtime library.
It needs the relevant java class, native library and assets.

Copy them in target prepare_xwalk_app_template so that
they will included in generated tarball of app template.

BUG=https://github.com/crosswalk-project/crosswalk/issues/657
[Android] Only put necessary files in official archive

The official archive will only include:
1. Runtime Library apk;
2. Hello World apk;
3. Application template for developer.

BUG=https://github.com/crosswalk-project/crosswalk/issues/753
Merge pull request #757 from wang16/official_archive

[Android] Only put necessary files in official archive
[Android] Use 'jsapi' instead of 'js_api' in extensions-config.json

Let's keep the consistency of using the jsapi. No need of '_'.
XWalkExtensionClient: do not warn in expected situations

Once XWalkExtensionClient decides to destroy an instance, it deletes
it but keeps it's id around waiting for server confirmation. The id is
associated with a NULL instance in the map.

When we send the DestroyInstance message to the server, it's already
marked that way in the client. So we may receive a pending PostMessage
from the server. In this case, we shouldn't warn, but simply ignore,
since there's no JS to send the message anymore.

We keep the warning for the case where after server confirmed the
destruction, we get another message. This will indicate a real problem
either in extension implementation or in the system.
Merge pull request #760 from cmarcelo/dont-warn-for-pending-message

XWalkExtensionClient: do not warn in expected situations
Make extension process dump stacktrace when crashing in debug mode
Bump version to 1.29.8.0
Merge branch 'master' of github.com:crosswalk-project/crosswalk
[Tools] Remove bump-canary-version.sh.

It has been superseded by increment-version.py, and now that the canary
infrastructure has started using the new tool, we can safely remove the old
one.
Merge pull request #759 from yongsheng/smallfix

[Android] Use 'jsapi' instead of 'js_api' in extensions-config.json
Merge pull request #658 from wang16/embed

[Android] Implement runtime client with runtime library embedded