It is risky and clunky to have API/ABI in control of a transpiler
like Vala is. Examples are:

- Defining the abstract classes in vala necessarily exports these
  *_construct() functions, which are 100% useless as public API
  since no subclassing of Tracker objects is whatsoever allowed
  outside of Tracker.
- While on the *_construct() functions topic, adding a constructor
  like tracker_sparql_connetion_new() somehow made valac stop
  exporting one for TrackerSparqlConnection. The warnings are
  somehow eaten when compiling the resulting C code, but hell breaks
  loose when the C compiler assumes an int return value (because
  it can't know better) but the constructor has a pointer-sized
  return value. Since those functions are exported, this change
  sneakily involves an ABI break too.
- Even though we want some properties to be construct-only, vala
  will automatically export setter functions for those. This adds
  API like tracker_sparql_statement_set_connection() that can only
  break things if ever called.
- The --abi-stability valac toggle was added too late for Tracker
  to use it. We could use 3.0 as an excuse to turn it on, but that
  doesn't magically fix the other points.
- Vala doesn't allow us to be explicit wrt the exported functions
  (eg. through extern). We do resort to a .map file, but that's
  prone to errors and hairy to maintain.

We still use vala at places for internal code, but I can't bring
myself to think it's a good idea to keep vala in charge of our
public API and ABI.