[Android] Refine the code and case of make_apk_test.

1. Reorganize the test cases for different mode option.
2. Add test case for checking the scenario without '--mode' option.
3. Add RunCommand function to reduce the code duplication.
4. Move the static function together.
[SysApps] Implement the Device Capabilities getMemoryInfo()

This is probably the easiest to implement and the most portable API. It could be
implemented without a "provider", but let's just keep using the pattern to make
the implementation more coherent.

We are using the Chromium abstractions, so it should work on all platform
supported by Chromium with no need of provider abstractions.
[SysApps] Add unit tests and browser tests for getMemoryInfo()
Move ApplicationStorageImpl files to browser folder

Move ApplicationStorageImpl files to browser folder: it should be in the same folder with ApplicationStorage.
Also ApplicationStorageImpl class should be included only in the one file - application_storage.cc, so ApplicationStorage class should use forward declaration to declare "impl" pointer.
[Extensions] Make it "safe" to use v8 after a WillReleaseScriptContext.

Before this patch, running ./out/Release/xwalk_browsertest --single-process
--gtest_filter="ExternalExtensionTest.ExternalExtension" was leading to a crash at RP with the following trace:

[0x0000014ba080] v8::Object::Delete()
[0x000000e5af67] xwalk::extensions::XWalkExtensionModule::~XWalkExtensionModule()
[0x000000e5d24f] xwalk::extensions::XWalkModuleSystem::DeleteExtensionModules()
[0x000000e5dfd5] xwalk::extensions::XWalkModuleSystem::~XWalkModuleSystem()
[0x000000e5e104] xwalk::extensions::XWalkModuleSystem::ResetModuleSystemFromContext()
[0x000000e5b079] xwalk::extensions::XWalkExtensionRendererController::WillReleaseScriptContext()
[0x0000025dc923] WebCore::V8WindowShell::disposeContext()
[0x0000025acf3d] WebCore::ScriptController::clearForClose()

This was happening because we thought that just using v8 at ~XWalkExtensionModule() was safe,
hence that we had an "already entered" v8::Context and could just perform any v8 operation.
It turns out we were wrong.

By having a look at WebCore::V8WindowShell, we can see that the function calling
WillReleaseScriptContext is V8WindowShell::disposeContext(). The callers from
that function sometimes "enter" their v8::Context by using a v8::Context::Scope,
but sometimes they don't. For instance, V8WindowShell::clearForNavigation() has
a context Scope on it (before calling disposeContext()), but V8WindowShell::clearForClose
doesn't. That explains why browsertests that doesn't have any sort of navigation were
crashing, while the others weren't.

When asking on #blink @freenode, I was told that "it doesn't seem strictly necessary to create
a Context::Scope for willRelease(). If the embedder needs to call into some V8 API that
expects being in some context, they can do it themselves.". Thus, this patch.

BUG=https://crosswalk-project.org/jira/browse/XWALK-718
TEST=./out/Release/xwalk_browsertest --single-process --gtest_filter="ExternalExtensionTest.ExternalExtension"
Merge pull request #1352 from junmin-zhu/withoutmode

[Android] Refine the code and case of make_apk_test.
[Contact] Expose interfaces and refactor unit test

According to spec, interface of Contacts, ContactField, ContactTelField,
etc. should be exposed to user.

Also including fixing of finding option, impp handling, and note data map.
Introduce Application class

Application class was born, RuntimeRegistry and ApplicationProcessManager are killed.

The newly added Application class is representing a "running application" accordingly to design described at https://docs.google.com/a/intel.com/document/d/1N0VVlut7JCWFbAEwTQc0loN9_D2JlOXRJprQeCbXY2U/ .

The in-browser tests were modified accordingly.
Merge pull request #1371 from pozdnyakov/Introduce_Application

Introduce Application class
Merge pull request #1318 from deqing/contact-unit-test

[Contact] Refactor unit test
Merge pull request #1379 from jeez/fix-v8-safeness

[Extensions] Make it "safe" to use v8 after a WillReleaseScriptContext.
Merge pull request #1378 from pozdnyakov/Move_Application_Storage_Impl_to_browser

Move ApplicationStorageImpl files to browser folder
Merge pull request #1376 from tmpsantos/devcap_memory

[SysApps] Implement the Device Capabilities getMemoryInfo()
Bump version to 4.32.58.0
Merge branch 'master' of github.com:crosswalk-project/crosswalk
Add Ozone-Wayland support
DEPS.xwalk: Point to our own Mesa fork for ozone-wayland support.
DEPS.xwalk: Track ozone-wayland.git.

This is a very important part of the process, as the code expects ozone/ to
be in src/.
[Packaging] Tune crosswalk.spec for Tizen IVI and Ozone-Wayland.

On the Tizen side, moving to IVI (with more up-to-date packages and an
better, open graphics driver) allows us to drop a few patches and also start
using NSS instead of OpenSSL again.

In order to support Ozone-Wayland, we need to depend on a few more packages
and pass other flags to gyp.

The IME-related patch was disabled because there is no package providing
`scim.pc` and I could not check what should be used instead. Additionally,
we've stopped defining `tizen_mobile` because it activates code that is
X11-specific.

The generated RPMs have not been tested yet.
DEPS.xwalk: Track another ozone-wayland branch.

For now, the M32 work is taking place in the `Milestone-Santa' branch, so
track that one instead of `stable'.