Improve manifest handlers unit test utilities

This patch introduces functions creating default configuration
data for both manifest types (TYPE_MANIFEST and TYPE_WIDGET).
runtime: Add aura-only native support

This CL brings aura-only native support for the browser runtime, where views
toolkit dependency is opt out. This is particularly useful for embedded and
limited systems, where the runtime is used always as a fullscreen application
to the host window system. This is aimed to work with Ozone DRI or GBM
implementations.

Testing was performed on Ubuntu Linux 14.04 platform.

TEST= $ python xwalk/gyp_xwalk -Dchromeos=0 -Duse_ozone=1 -Dembedded=1 -Duse_udev=1 -Dozone_platform_gbm=1 -Dozone_platform_wayland=0 -Ddisable_nacl=1
      $ ninja -j16 -C out/Release xwalk
      $ ./out/Release/xwalk --ozone-platform=gbm http://hexgl.bkcore.com/play/
runtime: Add cmd line option for changing native host window bounds

Ideally we would like to use ui::DisplayConfigurator for hotplug the monitors
and set the host window bounds automatically based on their mode sizes. That's
not possible though cause Crosswalk embedded solution doesn't fetch ChromeOS
dependencies, which is where ui::DisplayConfigurator situates.

Our solution here therefore is to pass through command-line options the native
bounds, using --xwalk-host-window-bounds=800,600 (or whatever is the
appropriated monitor resolution). One would also just link this newly option
with sysfs output like --xwalk-host-window-bounds=`cat /sys/class/graphics/fb0/virtual_size`
Merge pull request #2637 from tiagovignatti/embedded

Crosswalk embedded support
The big in-browser tests classes clean-up

Removed lots of unneeded code and simplified some of the remaining.
Merge pull request #2659 from tweglarski/UnitTestUtilImprovements

Improve manifest handlers unit test utilities
[Tizen] xwalk.gyp: Do not special-case virtual_root_provider_tizen.cc.

There is no need to put that file inside a "tizen==1" condition, files
terminating in _tizen.cc are automatically excluded from the build on
other platforms.
Merge pull request #2667 from pozdnyakov/tests_cleanup

The big in-browser tests classes clean-up
Merge pull request #2668 from rakuco/tizen-move-file-to-generic-list

[Tizen] xwalk.gyp: Do not special-case virtual_root_provider_tizen.cc.
Bump version to 11.39.255.0
Merge branch 'master' of github.com-crosswalk:crosswalk-project/crosswalk
[Tizen] gyp: Centralize the dependency on libtzplatform-config.

pkg-config was being used to get libtzplatform-config's flags in both
build/system.gyp and xwalk.gyp. Do that in a single place,
build/system.gyp, instead, to reduce this needless duplication.

Since libtzplatform-config was part of the catch-all "tizen" target in
system.gyp, it has been split into its own separate target so that code
that only needs libtzplatform-config does not end up depending on
several other Tizen libraries as well.
[Tizen] Build with component=shared_library.

It is the first step required for our hacks and workarounds to separate
the building of Chromium's code from Crosswalk's and into separate RPMs.

This commit starts passing -Dcomponent=shared_library to gyp so that
instead of building most libraries we use as static libraries, we build
them as .so's that get installed into %{_libdir}/xwalk/lib.

They are not installed into %{_libdir} directly because:
 * These libraries are private and not expected to be used by any other
   package.
 * The executables we generate assume that these shared libraries are in
   a directory called "lib/" below their location. This is done
   automatically by gyp by setting the binaries' RPATH.

Consequently, xwalkctl and xwalk-launcher also needed to be moved from
%{_bindir} to %{_libdir}/lib/xwalk. The versions in %{_bindir} are now
small shell script wrappers that call the real binaries. The shell
script itself is a repurposed version of xwalk.in, which we had stopped
using since commit 08f95caf ("[Tizen] Do not install 'xwalk' binary to
'bin' directory").

BUG=XWALK-2571
[Tizen] Split the package into crosswalk-bin and crosswalk-libs.

crosswalk.spec has been split into crosswalk-bin.spec and
crosswalk-libs.spec, each of which generates a separate RPM package:

* crosswalk-bin: The actual Crosswalk web runtime with all the xwalk*
  binaries and supporting files (systemd and D-Bus service files, for
  example).

* crosswalk-libs: The Chromium shared libraries and supporting
  files (such as icudtl.dat) required by the crosswalk-bin RPM. It has
  no dependencies on any Tizen-specific packages/libraries.

The main goal of the split is to be able to build them
independently (and have them as separate projects in build.tizen.org).
This way, changes to Tizen libraries (or to src/xwalk itself) only cause
crosswalk-bin to be rebuilt. Building crosswalk-bin should take only a
few minutes (instead of the hours it took to build the whole Crosswalk
RPM before).

The README in packaging/ has been updated, and the TL;DR; version is
that one must now specify which package needs to be built when calling
gbs build:

  $ gbs build --spec crosswalk-bin.spec # or crosswalk-libs.spec

Building crosswalk-libs requires some trickery:

* First of all, we do not want to depend on any Tizen package, otherwise
  changes to them in tizen.org would automatically trigger a
  crosswalk-libs rebuild that can potentially take hours as described
  above.
  We solve this by introducing a "building_crosswalk_bin" variable (its
  default value is 1) to build/system.gyp, which already centralises all
  the detection of additional package dependencies and pkg-config calls.
  If it is 0, pkg-config will not be called at all in targets such as
  "tizen", which is what we want and do in crosswalk-libs.spec.

* Secondly, we need to build all the shared libraries that the Crosswalk
  binaries need. We cannot hardcode this list, so the only reliable and
  future-proof way of doing it is to use gyp's dump_dependency_json
  generator and parse the dependency graph it generates to determine
  which targets in src/ (but not src/xwalk) need to be built. This is
  what the newly-added print-chromium-deps.py script does.

As for crosswalk-bin, it requires some invasive changes to Chromium's
build system to avoid building all the heavy Chromium targets such as
"contents" or "blink_web". The bulk of the change is in
crosswalk-do-not-build-several-chromium-dependencies.patch. This patch
changes several targets in the build system so that they do not build or
generate any files and just pass "-l<target>" to the linker. In other
words, we trick the build system into assuming nothing needs to be built
and using the shared libraries crosswalk-libs has installed into
%{_libdir}/xwalk/lib instead. As the big description in the patch
mentions, maintaining this patch up-to-date across Chromium releases
requires manual intervention since targets and dependencies are very
likely to change every time. The amount of pain in the arse this is
going to represent over time is still to be determined.

Another noteworthy change is that libxwalk_backend_lib.so's installed
location has changed from %{_libdir}/xwalk to %{_libdir}/lib since we
need the latter anyway for all the other shared libraries. We then
employ a small amount of shell scripting to make sure it is not part of
the list of files we want in the crosswalk-libs RPM.

BUG=XWALK-2571