[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()
[Runtime] Move initialization of XWalkRuntimeFeatures

Move this out from XWalkContentBrowserClient::CreateBrowserMainParts()
to a point earlier and more adequated for that initialization.
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"
[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()
Application Storage ownership

Application storage should be owned by application system and then it should be given to anyone interested in it (including Application Service).
The benefits:
- those who need storage but do not need service now are able to get it from ApplicationSystem directly
- initialization order of storage and service is easier to handle (now it is being handled from the generic place - ApplicationSystem)
- we're decoupling storage and service and ApplicationService interface can be cleaned from unneeded methods.
Bump version to 4.32.58.0
Merge branch 'master' of github.com:crosswalk-project/crosswalk
Merge pull request #1384 from pozdnyakov/Make_AppSystem_own_AppStorage

Fix Application Storage ownership
Roll chromium-crosswalk to 6d2ee63.

6d2ee63 [SysApps] Make CodecIDToAudioCodec and CodecIDToVideoCodec available as global functions
42904e0 [Android] Use application context for shared pref's creation
7e2e0a5 [Tizen][Android] Add Vibration provider api
7bcdb95 [Android] Use application context for shared pref's creation
e7273a6 [Android] Set webaudio to be muted when volume is set to 0
Fix tizen build after efb5f4d14585f59f947790637aed3b57b4c05775 (PR#1384)
Merge pull request #1385 from nagineni/deps_xwalk

Roll chromium-crosswalk to 6d2ee63.
Merge pull request #1386 from pozdnyakov/Fix_tizen_build

Fix tizen build after efb5f4d14585f59f947790637aed3b57b4c05775 (PR#1384)