[Runtime] Enable to update a web application from local

A web application can be updated from local when using "--install" switch
in command line, like this:
$ xwalk --install /path/to/xpk_package.xpk
If the application has been installed, WRT will try to update it.

https://crosswalk-project.org/jira/browse/XWALK-463
[Runtime] Re-factor for Install & Update methods in ApplicationService class
[Android] Fix packaging tool can't work on python3.0+.

1. Change print to print function.
2. Change "except" expression for try..catch
3. Add decode("utf-8") for output of subprocess
4. Change "filter" and "file" uncompatible usage.
5. Move ant.py and md5_check.py into xwalk, which request modification.

BUG=https://crosswalk-project.org/jira/browse/XWALK-766
XWalk should support source id when using getUserMedia API

XWalk can't choose camera and microphone according to the source id, this is
because XWalk is always getting the default devices, and ignore the requested
devices id even if the source id is specified.

Test: https://simpl.info/getusermedia/sources/index.html

BUG=https://crosswalk-project.org/jira/browse/XWALK-854
[Runtime] Fix the bug that one XPK package can install multiple times
without any error report.

The XPK package should generate the application id using public key
which is contained in the header of XPK package.

BUG=https://crosswalk-project.org/jira/browse/XWALK-883
Merge pull request #1513 from takethathe/update

[Runtime] Enable to update a web application from local
Merge pull request #1520 from takethathe/install

[Runtime] It should not be possible to install a XPK package multiple times
[Android] Add support for setting version codes in apk

Add support for specifying android version codes, which is necessary
for publishing multiple apk to google play. Follows the recommendation
for ABI in
http://software.intel.com/en-us/blogs/2012/11/12/how-to-publish-your-apps-on-google-play-for-x86-based-android-devices-using

Added some tests to make_apk_test and published x86 and arm crosswalk
apk to google play.

Addressed review comments
[Application][D-Bus] Unlisten for D-Bus name with the correct callback

When running xwalk --run-as-service in Debug mode, Crosswalk was
crashing during shutdown. Reason was that we were creating a new
base::Callback() via bind to unlisten, but we need to use the
same instance.

This commit stores the callback instance so we can unlisten the
correct callback. Because the callback can be cleared, we can use
it instead of keeping a separated boolean.

We also change the destructor logic slightly: we don't ask the
application termination from it anymore, just unlisten the owner (if
necessary). The destructor is called in two situations

  (a) by the manager when application will be destroyed;
  (b) when shutting down the manager.

For (a) asking the application to be terminated is redundant, and
for (b) the fact that the D-Bus interface is going away shouldn't
necessarily imply that we terminate the applications, the regular
Crosswalk shutdown will take care of this.

TEST=Run out/Debug/xwalk --run-as-service and xwalkctl <APP_ID> then
close the window. The first process should not crash but exit cleanly.
Merge pull request #1521 from yinli/getUserMedia

XWalk should support source id when using getUserMedia API
Merge pull request #1519 from cmarcelo/dbus-unlisten-wrong-callback

[Application][D-Bus] Unlisten for D-Bus name with the correct callback
[Runtime] Remove unused overload of Runtime::Create()

The extra Create() call is equivalent to Create() then calling
LoadURL(), but less readable.
Merge pull request #1522 from cmarcelo/remove-runtime-create-overload

[Runtime] Remove unused overload of Runtime::Create()
[Runtime] Fill the default window params in AttachWindow()

This makes Runtime::AttachWindow() more useful, since we can change just
some parameters for window creation and the defaults would still apply.
A later patch will make use of this to pass specific information from
the application launching to the native window creation (NET_WM_PID).

The fullscreen override was moved to that apply function, so strictly
speaking we can't attach a non-fullscreen window when the fullscreen is
passed. However, we were not trying to do this anyway. Added a comment
pointing that this policy check was probably in the wrong place.
[Application] Refactor the implementation of Application::Launch()

The goal of this refactor is to reduce to remove the duplicated logic
for runtime creation, so that we can change to pass more attributes in
the future.

This patch splits the logic for launching into

(a) figure out the right entry point, based on the launch params;
(b) create the runtime.

We have three possible entry points for (a), but the logic for (b) is
pretty much independent. While we still record the use entry point to
decide whether a window will be shown, there's no "tentantive steps" so
we can write only one code for (b).
Bump version to 4.32.76.0
Merge pull request #1524 from cmarcelo/refactor-application-launch-function

[Application] Refactor the implementation of Application::Launch()
Merge pull request #1523 from cmarcelo/fill-default-window-params

[Runtime] Fill the default window params in AttachWindow()
[Tizen] Fixed bug XWALK-881 Crosswalk doesn't support '--disable-device-capabilities' flag
Merge pull request #1526 from qjia7/master

[Tizen] Fixed bug XWALK-881 Crosswalk doesn't support '--disable-device-capabilities' flag