[Android] Fix that window.close is not working

Webapp might use window.close() to exit app.
This commit turns on the setting to allow this
usage and finish the activity when calling
window.close().

BUG=https://crosswalk-project.org/jira/browse/XWALK-939
[Android] Expose fullscreen related API to XWalkView

It's for embedder to customize the behavior of fullscreen
exiting in a flexible way.

BUG=https://crosswalk-project.org/jira/browse/XWALK-954
Merge pull request #1578 from wang16/window_close

[Android] Fix that window.close is not working
Merge pull request #1580 from wang16/view_fullscreen_api

[Android] Expose fullscreen related API to XWalkView
[Android] Launch Screen 1st-step implementation

This is the first step implementation of Launch Screen feature.

The workflow in general as below:
Build script:
1. Check whether 'launch-screen' provided in manifest.json.
2. Check 'launch-screen'->'default'->'image' field, and copy the image to 'res/drawable'
   Rename it as 'launchscreen.*'.
3. Set '@drawable/launchscreen' as window background, it will be displayed immediately
   after user tap the app icon.
Note: The drawable will be customized as the spec in the next implementation steps.

Runtime:
1. Check and get 'launch-screen'->'ready_when' field in manifest.json.
2. Display a dialog as launch screen, and set the background '@drawable/launchscreen'.
3. Hide the dialog depends on 'ready_when' condition:
   1. First rendered frame.
   2. First rendered frame & Page load finished
   3. First rendered frame & js:window.show()

TODO:
Test will be committed in another patch
Next step implementation will support the full spec.

Spec: https://docs.google.com/a/intel.com/document/d/17PuNuHRTQuREUpaCvj-eEx7uYi2avd-VW-oaMXMpvwo/edit?pli=1#
Design Doc: https://docs.google.com/a/intel.com/document/d/1YLajlZC7CkBOtEvzD6p6yeBr0HrPsaIGX8Eqhr3oTF4/edit#heading=h.mfsu3bk9566e
Bug: XWALK-637
Remove AUTHORS.

It has never been properly enforced and it does not have any effect for us.

We don't require a CLA, and we don't mention "The Crosswalk Authors" or
anything like that in the copyright headers on files.

Anyone can just send their patches and add their names as copyright holders
to the headers in the files they touch if the contributions are big enough.
[Android] Make the uid that can connect to the devtools server configurable

Currently, the devtools server allows only code running in the same process
to connect. This change allows specifying the process that can connect to
devtools server.

This code is being modified since the XDK architecture for remote debugging
has changed. Previously, App Analyzer had a websocket proxy that used to run
in the same process as xwalk. In the next version of XDK, the websocket proxy
is being moved to be part of another application (App Preview) and will run
in a process that is different from xwalk. With the addition of this API,
App Preview service will instruct App Analyzer to allow connections from
the service.

BUG=https://crosswalk-project.org/jira/browse/XWALK-964
Bump version to 5.32.89.0
Merge pull request #1582 from rakuco/goodbye-authors

Remove AUTHORS.
[Tizen] Remove Tizen 2.x-specific patches and code paths in the spec.

Now that we have finally moved away from Tizen 2, we can at last simplify
our spec file a bit and remove some patches that are not needed when
building for Tizen 3.
[Tizen] Fix the build after 22f2e19.

Remove references to AUTHORS from the spec file.

Pointy hat to:	rakuco
Merge pull request #1587 from rakuco/authors-build-fix

[Tizen] Fix the build after 22f2e19.
Bump version to 5.32.90.0
Merge pull request #1575 from gramakri-intel/devtools_allow_uid

[Android] Make the uid that can connect to the devtools server configurable
Merge pull request #1586 from rakuco/remove-tizen2-paths-in-spec

[Tizen] Remove Tizen 2.x-specific patches and code paths in the spec.
Merge pull request #1498 from kurli/launchScreen

[Android] Launch Screen 1st-step implementation
[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.