[Extensions] Fix entry points for Screen Orientation Extension

After commit 856353beba8a8318c51da3d672af187d7fd58ada, entitled
"[Extensions] Add a setter callback accessor to trampolines",
we can now use screen.onorientationchange as a valid entry point.
Merge pull request #1481 from jeez/fix-screen-orientation

[Extensions] Fix entry points for Screen Orientation Extension
Fix orientation sometimes getting stuck in current orientation after unlock

While we are locked the display_.rotation() can get out of sync with the
actual device orientation, so we need to find the best orientation given
the actual orientation, not the old one.
Merge pull request #1486 from kenchris/stuck

Fix orientation sometimes getting stuck in current orientation after unlock
Make sure screen.orientation is always valid

If the orientation has not been set by the extension yet, query it
synchronously.
Merge pull request #1488 from kenchris/sync

Make sure screen.orientation is always valid
Bump version to 4.32.71.0
[Application] Add permission storage logic

Permission storage: permissions should be stored in ApplicationData and
eventually the database, so now we have setter and getter in the
ApplicationData class and the actual db operations are done inside
ApplicationStorageImpl. While, there are still some parts missing, like
the session storage which should also be implemented in the Application
calss.
[Application] Added permission policy manager
[Application] Added permission getter/setters in applicaiton

Added session and persistent permission getter/setters. Also moved
permission policy manager into application system. Moved permission
initialization logic out of application data, i.e. the application
data won't initialize itself.
[Application] Add permission check logic in application

* This method is used to check API Control. It queries permissions
 actions from policy storage and tell the result to extension.
[Extension] Add API for Check API Access Control

This API is for external extension developer. The API need to be called in the
implementation of each exported API in C or C++ code. For C extension
implantation, header file "public/XW_Extension_Permissions.h" should be
included. For each API that need access sensitive data, developer should call
CheckAPIAccessControl for API control. For C++ extension implantation, header
file "xwalk/common/xwalk_external_extension.h" should be included.

The basic flow of API access control is as below:
1.when render process execute a JS API which need access sensitive data
of device, render process send a message to extension process
2.in extension process API's implemetation, it should call
  checkAPIAccessControl, which will call PermissionsDelegate
  (which is in also extension process).
3. extension process send a message to browser process.
   XWalkExtensionProcessHost -> XWalkExtensionProcessHost::Delegate
   (which is XWalkExtensionService) -> XWalkExtensionService::Delegate
   (which is XWalkAppExtensionBridge) ->xwalk::application::
   ApplicationService::CheckAPIAccessControl().
[Extension] Added APIs for permission-function register.

The runtime permission mapping is registered by extension which
implements some specific API, for example: "bluetooth" ->
"bluetooth.read, bluetooth.write, bluetooth.management" Whenever there
comes a API permission request, we can tell whether this API is
registered, if yes, return the according permission name.