[Mac] Fix the build

[chromium-style] Overriding method must have "virtual" keyword.
Build fix, destructor must be virtual

RuntimeRegistryObserver has virtual methods, so destructor must be virtual.
This check is enforced on the Mac and the build fails.
Don't use namespace directive in global context in header

On Mac, the build fails with
../../xwalk/sysapps/raw_socket/raw_socket_object.h:11:31: error: using namespace directive in global context in header [-Werror,-Wheader-hygiene]
Sort file names in xwalk_application.gypi
[Packaging] Introduce gbp-flat-tree.sh to simplify the Tizen build process.

TL;DR: one can simply do the following to build an RPM:
  cd /path/to/src/xwalk
  gbs build -A i586

We can get rid of the need for a separate git tree and the
generate-flat-tree.sh script by relying on the hooks provided by
git-buildpackage: the postexport hook that we use is called right after the
git repository's sources have been exported with `git archive`.

In this hook, we execute a new script, `gbp-flat-tree.sh`. It does pretty
much the same thing as generate-flat-script.sh, but automatically. That is,
it removes the tarball generated by `git archive` (since gbs build should be
called from xwalk/, it would only contain Crosswalk's contents anyway) and
replaces it with a new one with the contents of src/.

Since it is called at a stage in the whole build process that immediately
precedes the call to `/usr/bin/build`, we do not need to keep a separate
flat git tree with all our sources anymore; we are effectively bypassing
git-buildpackage's default export mechanism.

The downside of this approach (which is shared by the previous one with
`generate-flat-tree.sh`, anyway) is that all files in src/ are archived,
even if they are not part of any commit. In other words, we end up acting as
if "--include-all" was always passed to `gbs build`.

(Fun fact: the whole dance of calling `gclient recursive` twice with
different arguments and everything was unnecessary; one of the entries
reported by those calls is src/ itself, so we always ended up archiving
everything under it)
[Packaging] Accept other build directories to support incremental builds.

TL;DR: Specify a directory outside the RPM build area with the BUILDDIR_NAME
macro to have incremental builds:
  cd /path/to/src/xwalk
  gbs build -A i586 --define 'BUILDDIR_NAME /tmp/crosswalk-builddir'

A full rebuild was being performed in every call to `gbs build` due to two
issues:

1. rpmbuild erases the RPM build directory by default in the %setup stage of
   the spec file. This can be solved by passing -D to %setup, but...
2. osc-build (`/usr/bin/build`) removes the whole RPM build area (that is,
   `/home/abuild/rpmbuild`) by default unless we pass "--incremental" to
   `gbs build`. Unfortunately, suffice it to say that the implementation of
   that option in gbs leaves a lot to be desired and does not solve our
   problem.

This can be solved by exploiting the way gyp generates Makefiles: it is
possible to override the default value "out" of the `builddir_name` variable
and have out-of-source builds. We can thus point it to a location outside
`/home/abuild/rpmbuild` in the chroot and automatically preserve it across
builds, as the rest of the buildroot is kept by gbs by default.

We then allow the user to specify a different build directory with the
`BUILDDIR_NAME` RPM macro that can be passed to gbs as explained in the
beginning of the commit message. One of Chromium's tools, grit, also had to
be fixed to allow out-of-source builds to work correctly, which explains the
addition in DEPS.xwalk.

Another thing worth mentioning is that we now use the `-n` option of the
%setup macro in the spec file as the root directory of the source tarballs
do not have Crosswalk's version anymore: even if those two problems related
to the removal of the build directory above are worked around, a full
rebuild is triggered if the source directory gets changed (think of a
version number bump, for example). While at this, it is also worth bearing
in mind that a change in CFLAGS or CXXFLAGS also triggers a rebuild, so
calling make directly from inside the gbs chroot without using the same
compiler flags as the RPM build will also cause problems.

Last but not least, the generate-flat-tree.sh script and its instructions in
the README will be removed in a later commit, once we get more people to
test the new solution.
[Packaging] Update the README after the last two commits.
Add Caio to the root owners.
Merge pull request #1129 from darktears/caio-root

Add Caio to the root owners.
[Application] Fix loading local files

Only try to launch an application from the command line if it is a valid
Application ID. This was missed from the last batch of changes.
Merge pull request #1127 from rakuco/tizen-incremental

[Packaging] Improve support for incremental Tizen builds.
Merge pull request #1130 from cmarcelo/fix-loading-local-files

[Application] Fix loading local files
[Runtime] Remove unused includes from runtime.cc
Merge pull request #1124 from gramakri-intel/buildfix

Build fix, destructor must be virtual
Merge pull request #1112 from poussa/mac-compile-9

[Mac] Fix the build
Merge pull request #1131 from jeez/clean-up

[Runtime] Remove unused includes from runtime.cc
Merge pull request #1125 from mbbill/patch-3

Sort file names in xwalk_application.gypi
Bump version to 3.31.35.0
[Android] Add orientation support in the packaging tool.

Support the developer to set the display of app on device through
the option of packing tool. Such as: --orientation=landscape.
The default value is "unspecified".
The value options are the same as those on the Android:
http://developer.android.com/guide/topics/manifest/activity-element.html#screen
[Android] Make xwalk_core_library compilable on Windows

On windows, python is python.bat or python.exe.
Directly exec python will fail.
To detect which extension is used. Add condition
and "where" exec in precompile.xml to determine
the final extension string for python.

BUG=https://crosswalk-project.org/jira/browse/XWALK-335