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.

We don't want to index or do any extra work on node_modules because they
are not in direct control by the project. It also increases the chances we
do an insane amount of extra work (like code indexing, etc).

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.

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

Which allows one to specify what to run in package.json, as the
"start" script (a node.js convention), and then uses npm to run it.

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

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.

Giovanni Campagna authored Jun 29, 2017 and Christian Hergert committed Jun 29, 2017

Recognizes "package.json" as a valid project file (instead of using
the directory type), and runs "npm install" while building.

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