Add application extension and getManifest(), getMainDocument() API support

The application extension is an internal extension to handle application level
APIs(e.g., runtime events, manifest, package management, etc.).

In this commit two APIs is added, one is xwalk.application.getManifest(see
http://developer.chrome.com/apps/runtime.html#method-getManifest), the other is
xwalk.application.getMainDocument(see
http://developer.chrome.com/apps/runtime.html#method-getBackgroundPage).

We use asynchronous calls for both of these two APIs. getManifest() will
retrieve current running application's manifest dictionary value and post the
value to renderer. getMainDocument() utilizes ApplicationNativeModule to get
RenderView from the main document's routing ID, then return its main frame
global JS object.
Add application browser test base class and application API browser test

ApplicationBrowserTest is a base class for application browser test. Currently
it only provides Runtime status check. It will support other application test
utilities after shared browser process model is supported.

In this commit getManifest() and getMainDocument() API tests are added.
Bump chromium-crosswalk in DEPS.xwalk.

Bring in the fix in chromium to fix the rendering issue
of content shell when using single process on Android.
Merge pull request #923 from wang16/roll_deps

Bump chromium-crosswalk in DEPS.xwalk.
[Android] Refine the xwalk_core_test_apk target

This fix is to refine the test target to make it more cleaner to add
HTML testing file as apk asset file. Right now, when adding a new HTML
file for testing, you just need to update the 'sources' list without
adding a new entry item in 'copies' list.
Merge pull request #612 from seanlong/xiang_api

[Runtime] Add application extension skeleton and getManifest, getMainDocument API support
[Extensions] Refactoring XWalkExtensionService::RegisterExtension

Nowadays our XWalkExtensionService is only capable of handling
one RenderProcess. Thus, it only has one in_process XWalkExtensionServer
for handling internal extensions. Soon enough this will considerably
change and we will have to be capable of handling one in_process
XWalkExtensionServer per RenderProcess.

This patch is the first step towards this: internal extensions
will be created directly by the XWalkExtensionService::Delegate
"on-demand" every time a new in_process XWalkExtensionServer
is created for a new RenderProcess and it is time to register
the internal extensions on it.

The entity implementing XWalkExtensionService::Delegate is
XWalkBrowserMainParts. This way we keep the old behavior and design
not polluting XWalkExtensionService.

Necessary adjustments were made to RegisterExtensionsCallback and
browser_tests for the same reason.
Enable multithreaded GPU compositing of web content by default.

Enable multithreaded GPU compositing of web content by default, this also enables pinch gesture support on Tizen.
Merge pull request #933 from pozdnyakov/EnableThreadedCompositing

Enable multithreaded GPU compositing of web content by default.
[Extensions] Remove unused function
[Extensions][Android] Make CreateExtension call XWalkExtensionService directly

XWalkBrowserMainParts is now a XWalkExtensionService::Delegate, meaning that
XWalkExtensionService will call RegisterInternalExtensionsInServer everytime
a new in_process XWalkExtensionServer is created (for a new RenderProcess).

Therefore, XWalkExtensionService::RegisterExtension() has been removed
and XWalkExtensionAndroid will now need to register its extensions on
XWalkBrowserMainParts so them can get correctly registered on-demand
by XWalkExtensionService.
Merge pull request #934 from cmarcelo/remove-dead-code

[Extensions] Remove unused function
[Extensions] Use a vector instead of a map for extension modules

In XWalkModuleSystem, use a vector instead of a map for extension
modules. The number of modules is small and we'll benefit from being
able to easily get sorted iteration later to identify the extension
modules that can be loaded on demand.
Merge pull request #910 from jeez/refactor-register-extension

[Extensions] Refactoring XWalkExtensionService::RegisterExtension
Merge pull request #937 from cmarcelo/extension-modules-vector

[Extensions] Use a vector instead of a map for extension modules
Bump version to 2.31.21.0
Merge pull request #931 from hmin/refine-test-target

[Android] Refine the xwalk_core_test_apk target
[Android] Fix #705 to support multiple frames for extension mechanism

When there are multiple frames in one page, extension instance will
be created for each frame. But as internal WebFrame is not exposed
in Java side, there is no way for Java side to identify which
instance to send message. This patch exposed instanceID up to Java
side when it receives message which can be used to identify the
target instance when post message to JavaScript side. What's more
a new interface "broadcastMessage" was added to meet the requirement
that Java side may need to broadcast message to all exiting instances.

Changed interfaces for Java extension:
1. postMessage(String msg) -> postMessage(int instanceID, String msg)
2. onMessage(String msg)   -> onMessage(int instanceID, String msg)
3. onSyncMessage(String msg) -> onSyncMessage(int instanceID, String msg)
4. new added: broadcastMessage(String msg)

BUG=#705