This can be a directory now, which breaks the normal Cargo.toml expectation
we had previously.

Fixes #770

This renames IdeBuildPipeline to IdePipeline and IdeBuildStage to
IdePipelineStage. Additionally, IdeBuildPhase is now IdePipelinePhase.

This should help in contributors understanding the difference between
the IdeBuildSystem components and the production pipeline and it's
components.

I didn't try very hard to keep whitespace nice, because we'll probably
do a large round of that with automation tools later and I'd rather do
that as a single pass.

Also, I renamed the execute APIs to build since execute didn't really
make sense in the concepts of a build pipeline that can
build/rebuild/clean.

I would not be surprised if there is a bit of fallout from this, so better
to get it in now than later.

This ports the cargo plugin to use the new libide-foundry design.

Various build options must go before --

Jacob Humphrey authored Aug 03, 2018 and Christian Hergert committed Aug 06, 2018

Signed-off-by: Ricardo Silva Veloso <ricvelozo@gmail.com>

Corentin Noël authored Mar 29, 2018 and Christian Hergert committed Apr 09, 2018

This avoids the creation of three properties everywhere and is more
future-proof (It already supports the quadruplets but can be extended as
needed).  This also avoid string duplication in every classes.

Our templates have moved away from this, and we can remove it from our
sources too.

We don't know for sure if the build needs to be run, so we must
always defer to cargo to run "cargo build".

Lower integral value is better.

These are a bunch of pipeline addins which were not yet setting
build stage names (and is now more necessary with the panel view).

Add a way to find the programming language of a build target.
This will be used to weed out incompatible debuggers, profiling
tools, etc.

Cargo build targets are changed to return rust, NPM to return JS.
Similarly, a future Cabal integration should say Haskell, Maven or ANT
should say Java, etc.

For now, automake, meson and cmake return "asm" (native code),
because it's annoying to find if the build target is built from C,
C++, Vala or Fortran, and it does not matter too much because gdb
and valgrind can deal with it.

https://bugzilla.gnome.org/show_bug.cgi?id=790846

Implement the basics for the build target provider in cargo. We
still need to propagate the directory for which it must be
run as, so that cargo can find the proper information.

So that we can use this later when necessary outside of the
build pipeline.

As the project has grown, we've let things get a bit out of their
logical place. This does a bit of cleanup and tries to bring some
of the embedded resources closer to where they are used.

But more importantly, this allows us to clean some things up to
the point that we can move forward statically linking a bunch of
the plugins into libide. The plan here is to speed up the initial
loading by avoiding lots of disk I/O stats which are currently
hurting us.

If we get an error, we want to tell the user why with more information.

We might need to use an alternative cargo binary, so make that possible.

This allows for specifying a small identifier for the build system type
such as "autotools" or "cmake" or "meson" or "cargo".

We can use this in future patches for matching up a build system with
a given load hint.

https://bugzilla.gnome.org/show_bug.cgi?id=780006

Lower is better, and we want autotools to always be the preferred build
system until we have either 1) rearchitected multi-build systems or 2)
decided on another "blessed" build system.

This converts the cargo operations into a series of build stages to be
attached to the build pipeline.

Instead of having get_build_flags_async() and get_build_targets_async()
as part of the IdeBuildSystem, we've moved it to IdeBuilder. This allows
the build system to have an active configuration which is necessary for
many build systems to get accurate information.

They might be checking for NOT_SUPPORTED to determine the difference
between not supported and failed.

Now that we only have synchronous spawning, this can be renamed to
something simpler.

We really ought to make this (default 0) in introspection.

This doesn't yet handle running, so we still need to figure out how to
extract enough information to use our own runners instead of cargo run.