[Tizen] Move application binary path from .config to  TZ_USER_APP / TZ_SYS_RW_APP

user application binary is now located in TZ_USER_APP instead of /$HOME/.config
global application binary in TZ_SYS_RW_APP instead of /usr/apps/.config

BUG=XWALK-2672

Signed-off-by: Sabera Djelti (sdi2) <sabera.djelti@open.eurogiciel.org>
[Tizen] Remove Blink-Add-GCC-flag-Wno-narrowing-fix-64bits-build.patch.

Since b089b656 ("[Tizen] Stop unconditionally passing -Wall to the
compiler") we have stopped making the compiler generate more error
messages than intended. As that commit explains, Chromium has its own
mechanisms for deciding which parts of the code need -Wall and which
need it to be left out (since several pieces are built with -Werror),
and we should trust it to do the right thing.

This allows us to get rid of this patch since the code now builds
cleanly on both 32- and 64-bit architectures.

BUG=XWALK-917
Application: Add the check for return value.

The return value of getString() was not being checked.

CID=194038
BUG=XWALK-2928
Bump version to 11.39.249.0
ApplicationSystem: Initialize |params|.

The local variable was not being initialized in launch_params().

CID=194562
BUG=XWALK-2928
[Tizen] Parsing of app-control entry in widget manifest

In xml manifest, we have following structure of app-control entry:
<tizen:app-control>
    <tizen:src name="edit.html"/>
    <tizen:operation name="http://tizen.org/appcontrol/operation/edit"/>
    <tizen:mime name="image/jpg" />
    <tizen:uri name=""/>
</tizen:app-control>

Information about app-control should be passed to platform's manifest.xml
during installation of widget.

This information enables launching applications based on app control as
handler for given URI or MIME type.
Merge pull request #2592 from tiwanek/XWALK-1490

[Tizen] Parsing of app-control entry in widget manifest
[Tizen] Tune up app-widget element parsing in its manifest handler

Tizen 2.2 WRT Core Spec:
 - does not classify as invalid, widgets with:
   - more than one primary app-widgets,
   - no primary app-widget,
 - does specify that box-icon element is optional.

This patch removes unnecessary validation of primary attribute
in app-widget element and fixes parsing of box-icon element.

Link to the spec:
https://source.tizen.org/sites/default/files/page/tizen-2.2-wrt-core-spec.pdf
Merge pull request #2634 from tweglarski/AppWidgetTuneUp

[Tizen] Tune up app-widget element parsing in its manifest handler
Bump version to 11.39.250.0
[Tizen] Add explicit dependencies on some targets.

This fixes some issues with a component=shared_library build that just
made it evident that we were using code from some parts of Chromium
without depending on the targets:

* application/browser/application_tizen.cc uses ui::PlatformEventSource.
* runtime/browser/ui/splash_screen_tizen.cc uses
  ui::ImplicitAnimationObserver.
Merge pull request #2638 from rakuco/tizen-add-target-dependencies

[Tizen] Add explicit dependencies on some targets.
Bump version to 11.39.251.0
[Application] widget_handler: Add the check for return value.

The return value for GetString() was not being checked.

CID=194059
BUG=XWALK-2928
[Tizen] Fix multiple occurrences of author in widget setting.
According to widget spec(http://www.w3.org/TR/widgets/#the-author-element-and-its-attributes), the author element's occurrences should be zero or one.
If there are more than single occurrences, just read the first one and ignore others.

BUG=XWALK-2986
Merge pull request #2640 from yejingfu/fix-widget

[Tizen] Fix multiple occurrences of author in widget setting.
Merge pull request #2621 from rakuco/tizen-remove-blink-patch

[Tizen] Remove Blink-Add-GCC-flag-Wno-narrowing-fix-64bits-build.patch.
[Tizen] packaging: Always set the file permissions when calling install(1).

By default, install(1) installs everything with a permission of 0755,
which we do not need for anything but executables. Everything else is
installed with chmod 0644.

Be explicit and specify the permissions we want when installing all
files in the %install phase.

While here, regroup some calls to install(1) so that only binaries are
installed in the section we call "Binaries".
[Tizen] Start using binutils-gold for linking Crosswalk again.

Using the traditional BFD linker is causing problems with shared_library
builds on Tizen due to the way some parts of the code are built:

 * The geolocation support on Tizen is implemented by making the content
   layer call NewSystemLocationProvider(), which is then implemented in
   another target in xwalk/.
   With ld.bfd, this causes issues the linker not to find the
   implementation of content::NewSystemLocationProvider() since
   libcontent.so does not depend on the Crosswalk code that implements
   that function.

 * ozone-wayland adds some files to the views target, and requires
   symbols from them. However, due to circular dependency issues,
   libwayland.so does not depend on libviews.so.
   With ld.bfd, this causes linking to fail because libwayland.so cannot
   find an implementation for
   views::DesktopFactoryWayland::DesktopFactoryWayland() and
   views::DesktopFactoryWayland::~DesktopFactoryWayland().

Arguably, these can be considered actual issues with the code; on the
other hand, the gold linker seems to be smarter and finds those
implementations in separate libraries automatically without requiring us
to fiddle around with linker options (I am not even sure there is an
option to make this work with the BFD linker). Additionally, the binaries
generated by the gold linker have fewer DT_NEEDED entries so each binary
only depends on the shared libraries it actually uses.

In addition to depending on the binutils-gold package, the associated
gyp variables have all been set, so that we explicitly use the
system-wide binutils/linker instead of the ones in the Chromium
toolchain, use any additional useful gold flags. While here, we can also
stop setting the "linux_use_gold_binary" variable in the ARM case, as
that did not have any effect since M37. Last but not least, we need to
disable fatal warnings on all Tizen platforms now -- what was previously
failing only for Tizen Common because it was already using Chromium's
bundled gold is now failing everywhere.

One caveat is that this makes re-enabling NaCl support on Tizen a bit
more difficult. As explained in XWALK-1904, the way binutils is set up
on Tizen makes the ld_bfd.py not work as expected. In this respect, the
situation has not changed compared to when commit 55c37c0 ("Fix build :
Force ld.gold binary usage") was reverted. The difference here is that
NaCl support is currently disabled on all Tizen profiles and
architectures ever since we moved to Chromium M39, so we can now land
this change without having to worry about NaCl at all.

BUG=XWALK-1904
BUG=XWALK-2571
BUG=XWALK-2679
Bump version to 11.39.252.0