The AppData files provide descriptive data about an application, and is
typically used in application managers to display additional information to
the user. Having an AppData file is especially important for some graphical
application installers: without one, an application manager may not event
show an entry for the application. This happens for example in GNOME Software.

For the sake of completeness, this commit not only adds the AppData file to
the Flatpak build, but also to the Linux .deb and .rpm packages.

When storing the output of a Flatpak build to a commit into an OSTree
repository (by setting the $FLATPAK_REPO environment variable), it is
good to have a descriptive subject in the commit log message.

This makes the Flatpak builds honor the $FLATPAK_REPO environment variable.
When it is defined, it will be used as the path to an OSTree repository where
the Flatpak application bundle will be committed to. This allows to place
multiple builds in the same repository (along other applications, even), which
can be published. For more details abuit using repositories for publishing,
check:

   http://flatpak.org/developer.html#Distributing_Applications

Note that setting $FLATPAK_REPO disables building a standalone .flatpak bundle
file.

This honors the following environment variables:

- $GPG_KEY_ID: When set, it can be the identifier, full fingerprint, or
  email address of a GnuPG key which will be used to sign Flatpak builds.

- $GPG_HOMEDIR: Path to an alternative home directory to be used by GnuPG,
  instead of the default ~/.gnupg directory of the current user. This can
  be used to point GnuPG to a different keychain.

This adds support for building Flatpak application bundles, which should be
runnable on any Linux distribution with Flatpak support. See the page at
http://flatpak.org/getting.html

New Gulp tasks are added to prepare a directory with the needed files
(vscode-linux-${arch}-prepare-flatpak), assembling the Flatpak bundles
(vscode-linux-${arch}-flatpak), and for cleaning the build directories
(clean-vscode-linux-${arch}-flatpak). This mimics how the Debian and RPM
package creation works. Hence, building an application bundle is done with:

  $ gulp vscode-linux-x64-flatpak
  [...]
  $ ls *.flatpak
  com.visualstudio.code.oss-x86_64.flatpak

Installing and running the application is achieved with:

  $ flatpak --user install --bundle com.visualstudio.code.oss-x86_64.flatpak
  $ flatpak run com.visualstudio.code.oss

(Removing "--user" would install the application system-wide. Also note that
the "org.freedesktop.Platform" runtime needs to be installeed, check the
Flatpak website for instructions.)

The "flatpak-bundler" development dependency provides an asynchronous API to
invoke "flatpak-builder". The "gulp-image-resize" module is used to
incorporate scaling of the application icon to multiple sizes, and uses
ImageMagick (or GraphicsMagick) under the hood, which is commonly available on
most GNU/Linux distributions.

Instead of building the Electron dependencies ourselves, this uses the
io.atom.electron.BaseApp bundle as base application.

Instead of building the Electron dependencies, this reuses the
"io.atom.electron.BaseApp" bundle as base application. The contents of the
base application are imported at build time, and then Electron and the
prepared files added on top. The prebuilt base application will be fetched
automatically using the URL specified in the "baseFlatpakref" attribute of the
manifest, and it is kindly hosted at Amazon S3 by Endless Computers
(https://endlessm.com). The sources for the base application can be found at:

  https://github.com/endlessm/electron-flatpak-base-app/

Fixes #17133

Fixes #17142