This commit introduces the `DEFAULT_TOOLCHAINS` variable which contains
a list of toolchains (e.g., `arm mips`) to build by default. The default
value `all` builds all the available toolchains.

This commit also removes the `|` for order-only dependencies, which was
introduced due to a misunderstanding of how it works.

This commit imports `llvmcpy`, our Python library for interacting with
LLVM IR. To do so, the generation of the `environment` script has been
extended to export `PYTHONPATH`, so that `orchestra` users can easily
use our eggs.

To implement Python support in `orchestra`, we now provide the source
path to build and install stages too.

Removed the `prepend_path` function definition and "inlined" the path
prepending making use of a portable shell parameter expansion mechanism.

This change should make the environment script compatible with `zsh`,
`dash`, `sh` and `bash`.

Recent version of LLVM disable the `dump` method in `Release`
builds. This commit forces it to keep it enabled.

`toolchain.mk` used to contain the list of toolchains to build. Since
each toolchain uses (among other things) the last commit of
`toolchain.mk` to detect if a rebuild is required, this forced us to
rebuild all the toolchains each time a new toolchain is introduced.

This commit moves in a standalone file (`toolchains-list.mk`) the
toolchain list.

Instead of reinstalling all the build dependencies at each build we now
start from a Docker image which contains all of them and can be employed
as starting point.

For some reason, this dependency has been lost on the way.

This commits instruct the CI to install some additional dependencies:
valgrind, python-pygraphviz and python-pyelftools.

In case of failure of revamb's test, dump the test results on stdout, so
that it's available on the CI logs.

We statically link the `libstdc++` and `libgcc`. This commit prevents
ensures the `-static-libstdc++` option is not passed when compiling C
code.

By default, orchestra will try to use the branch employed by itself to
clone the repositories. However, this way, the master branch would be
used in most cases, while we want `develop` to be the default.

This commit blacklists the `master` branch for this purpose.

In the past we used to rebuild all the binary archives, always, no
matter what. This commit rebuilds a build only if the repository
associated to that build has a commit not available in the binary
archive or if the files that generated the corresponding component
changed.

For this reason, we also split Makefile in several smaller files we can
invoke `git log` on. In fact, to verify if the file that generated a
component has changed, we check the last commit affecting it.

`tempfile` is part of the debianutils package which is not widely
available. On the other hand, `mktemp`, being part of coreutils, is
available everywhere.

GCC 8 adds stricter tests for `-Wparentheses` warnings.  These warnings,
that happen to be triggered by the boost version we employ, cause
compilation failures when `revamb` is built with `-Werror` (like it's
mostly common in development).

I didn't want to remove or silence the warnings in `revamb`, since they
are sometimes useful to spot real bugs, so I backported here a patch
coming from upstream boost, which disables only this specific warning
and only for the interesting points where the boost developers have
already decided that it's not harmful to suppress these warnings.

`gcc-stage1` was not depending on `binutils`. Moreover, the
`environment` script is now regenerated whenever `Makefile` changes, so
that it gets regenerated when a new toolchain is added.

QEMU used to be built exclusively in debug mode. We know differentiated
the component in a `-debug` and a `-release` build. The main reason for
this is being able to fairly compare QEMU and revamb performances.

Since version 1.1.15 the musl buildsystem introduced a mechanism in the
configure script for autodetecting cross-compilation and setting the
CROSS_COMPILE environment variable accordingly if it was not set by the
caller.

This mechanism broke our build because:
1) we do not set CROSS_COMPILE even if we're cross compiling, so the new
musl configure sets CROSS_COMPILE automatically to the correct triple;
2) before this commit we didn't have in the gcc install directory and
the binutils install directory in PATH when compiling musl, so the build
system was not able to detect the proper build tools for cross
compilation.

Now we source the environment before building musl, so that we're sure
that the build tools with the proper cross-compilation triple are found
in the PATH.

We used to have the possibility to try to clone multiple times source
repositories, in case of network problems. However, only `git clone`
commands were retried, source tarballs fetched with `curl` were not.

This commit fixes this.

This commit tries (again) to fix dependencies issues that led to a
non-stable loop of builds when giving multiple times the same
command. The reason for this was that, for instance, `gcc-stage2`
installed `gcc`, which should be fine according to the latest attempt to
fix the problem, except for the fact that this means touching the file
`installed-targets/toolchain/*/gcc`, making it look newer and therefore
triggering rebuilds.

The solution is to introduce more explicitly the fact that a certain
build "provides" another build. For instance, `gcc-stage2` "provides"
`gcc-stage1` and `libc-default` "provides" `libc-headers`. A build that
provides another build will touch the corresponding install file, unless
it already exists. If it already exists, the file is left untouched,
preserving the dependencies graph in the right form.

In addition, dependencies are now separated between "configure-time" and
"install-time". Install-time are always required, while configure-time
dependencies are required only if we're building from source.

* The concept of providing another build is represented by the
  `_PROVIDES` build variable.
* The distinction between configure-time and install-time dependencies
  is expressed by differentiating the `_CONFIGURE_DEPS` and
  `_INSTALL_DEPS` build variables.
* For improved readibility, this commit now splits `$(calls)` onto
  multiple lines. However, when this is done, the call has to be wrapped
  in another function that strips from whitespace each argument.
* In `toolchain.mk`, the order in which the libc and GCC components are
  generated has been changed, so that we can correctly depend on `gcc`
  being installed before building the libc and `gcc-stage2` can depend
  on libc being installed before building.

This commit does two things: introduces support for automatically
building (and pushing to the binary-archives git-lfs repository) binary
archives, and introduces support for installing component builds as
binaries fetched by the above mentioned repository.

* A `.gitlab-ci.yml` file has been created. It installs all the
  necessary dependencies to run revamb tests successfully within a clean
  Ubuntu 16.04 docker container.
* This commit introduces the `BINARY_COMPONENTS` variable, which
  contains the list of components which should not be built from source,
  but should be installed from the provided binaries instead.
* Infrastructure to commit and push automatically to
  binary-archives. The credentials have to be provided through
  environment variables.
* Infrastructure to automatically extract and install from binary
  archives. The dependency system is changed to respect the directives
  of the `BINARY_COMPONENTS` variable.
* A simple Python script to fetch files from git-lfs repositories has
  been imported. This avoids forcing users to install git-lfs, which is
  not generally packaged by major Linux distributions. Note that to push
  to binary-archives, a proper git-lfs installation is required.