[DO NOT MERGE] [Application] Implementation of application permission system.

**This patch contains following major parts implemented step-by-step:** completed steps are marked as [x]

- [x] Permission check: it's unfinished because some of it's logic need to be put into the Application class which does not exist for the moment, the corresponding code in ApplicationService is ready though. The remaining tasks are marked by TODOs (Update: the missing parts are completed in the 4th commit in the PR)

- [x] 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.

- [x] Permission message passing (on going): It's merged from Xu,Zhang's PR #1231 .
The following comments are copied from PR #1231

  This PR is related to API Access Control feature: communication functionality between extension and browser process.
  In this PR, a new API is public for extension developer to enforce API permission checking. The whole API Access Control feature is composed of a few PRs. This PR is one of them. Another PR related to this feature is PR#1176:Added permission group and policy management classes.
The design document of this feature can be found from https://docs.google.com/a/intel.com/document/d/137u_gxmNaIFwVzaCkCFBJyveIdZxuAydWOkMI8oWgD0/edit#heading=h.5rkmb0mvstye

- [x] Fully integrate Zhang,Xu's IPC code, make the permission definitions, method names align.

- [x] Switching to async response in permission check API. After this step is done, we will have a working permission system.

- [x] Permission-function register.

  One extension may provide one or more (typically only one) set of APIs that are under corresponding permission label. For example, one extension may implement all the bluetooth.xxx() functions under permission name 'bluetooth', or more detailed permission name 'bluetooth.read, bluetooth.write, bluetooth.management' (it depends on how permission catagory is defined). The extension is responsible for registering its implemented functions and permissions after being loaded by extension system by calling a permission register function with it's permission-function mapping. The mapping is JSON string (being defined) which may look like
```
{ "bluetooth":  ["bluetooth.read", "bluetooth.write"] }
```

----
**The following features will be included In the next PR**
- [ ] Define the permission-function register format.
- [ ] Make the "CheckAPIAccessControl" work for in-process extensions.
 - [x] Move permission delegate from XwalkExternalExtension to the XwalkExtension class.
 - [ ] Implement permission delegate for in-process extensions.
- [ ] OEM policy define and implementation.

- [ ] UI dialog.

- [ ] Permission cache in extension process

**Relation with other permission-related patches**
 - Because of the refactor of storage system and to fit in the future application architecture, this patch deprecates the previous PR #1176

 - Because the permission messaging API are merged into this patch, this patch deprecates PR #1231

**Some Term Explanations:**
 - Runtime Permission:

 Permission name used by runtime/extension/render process to determine a appropriate operation for a permission request.

 - Stored Permission:

 Permission name that would be stored into database during installation or after a user interaction.