This adds more detailed information about gobject-introspection, as well
as how to build vala API descriptions.  It also includes information
about detecting the presence of library functions, libm, and shipping
the meson build files in the autotools tarball.

See:
https://lists.gnu.org/archive/html/bug-gettext/2024-05/msg00014.html

One of these may be the empty string, if either the autotools build or
meson build is missing.  Passing the variables bare will make the
command line think there's nothing there at all, but quoting an empty
string acts as an empty string command line argument, which 'git diff'
will get confused by.

Usually it's of course a good practice to quote variables that contain
filenames, since they could have spaces in them or other shell-unsafe
characters.  But in this case we know the variable will contain a string
that consists of only letters and dots.

Closes: #65

Without this, the first command in the list gets run in xfce-build, but
the rest get run outside the container on the host system.

Sometimes disabling one or the other will result in a different ABI, so
just disable the check for those builds.

A CI variable called ABI_CHECK needs to be set in the repository
configuration.  It should be a space-separated list of colon-separated
symbol-path + library-filename pairs.

(The symbol path should be a repository-root-relative path to the
.symbols file, while the library filename should just be the filename,
and CI will attempt to find it inside the repository.)

It seems that all the library projects have their own copies of this,
which seems kinda silly.  And there are some downsides to those files:

* The visibility alias file generation script is written in perl.  This
  isn't generally a bad thing, but requires people have perl installed.
  With the meson build, python will be required, so might as well write
  it in python.
* The symbols file consumed by the scripts is a C preprocessor file, and
  its a bit tedious, annoying, and error-prone to write.  The new format
  that the new scripts consume is simple and easy to read and write.

There was also never really any documentation for how to set all this
up, so I've written a README that describes the process for both
autotools and meson.

Adds VERSION_FULL and PACKAGE_VERSION_FULL to xfce-revision.h, which can
be more easily used in apps.

Fixes version component splitting; previously it split on 'git', but it
should be '-dev' now.

Adds a 'version_short' meson.build variable for convenience.

xfdesktop will be needing it soon.

Soon this will be needed by libxfce4windowing.

And some other packages needed by apps/catfish!60.

I had originally used a log file in !101 because clang-format-diff <= 17
didn't emit an error code in the event of non-empty output, but this is
no longer the case with clang-format-diff >=18, so the use of this file
is no longer justified.

Amends: cbbceb2fa207a56a74abf77d14054b76a201ba03

i.e. for commits on default branch and merge requests against default
branch. Do not run these jobs for tags, it's pretty useless and would
force us to distinguish between tags on default branch and tags on
maintenance branches.

Do not run these jobs on translation commits either, since in this case
the build jobs didn't run (unfortunately 'needs' doesn't handle this
automatically).

Amends: 8bf2175d178313c2b6b6a7efb634cd98917c2290

Otherwise, it's possible for a pattern to correspond to several
warnings, not all of which are false positives. By adding sufficiently
precise patterns as indicated in the comments, this is unlikely, but not
impossible.

In the case of this pattern, for example, currently present in
xfce4-panel:
tasklist-widget.c:[0-9]+:[0-9]+: warning: dereference of NULL 'child' \[CWE-476\] \[-Wanalyzer-null-dereference\]
the 'child' variable has enough occurrences in the tasklist-widget.c
file that the risk of a multiple match cannot be ruled out.

The simplest way to specify a multiple match seems to be to add the
pattern several times, instead of specifying the number of matches,
which would require additional parsing with a delimiter.

Amends: 8bf2175d178313c2b6b6a7efb634cd98917c2290

This may be necessary in certain situations, for example when performing
static analysis with scan-build, to ensure that the standard C++ library
is added to the linker. See
panel-plugins/xfce4-sensors-plugin#48 (comment 90769)

Otherwise it overrides CC and uses the default compiler, i.e. gcc in our
case, making build-clang a duplicate of build-gcc + scan-build.

Fixes: 8bf2175d178313c2b6b6a7efb634cd98917c2290

This requires extra effort on the part of maintainers, and is therefore
disabled by default. To activate these jobs, you need to add the CI/CD
variables GCC_ANALYZER and/or SCAN_BUILD to each project.

These static analysis tools are quite prone to false positives, so for
these jobs to be useful, it seems the right approach is to not allow
them to fail and maintain false positive files (otherwise we risk
getting used to seeing them fail and simply not paying attention). How
to fill in these files is indicated in the comments.

As we only change software versions every two years in CI, the extra
maintenance effort should be quite small though, once the first warnings
have been fixed or ignored. The fact remains, however, that their
analysis can be more tortuous and time-consuming than that of simple
compiler warnings.

Also, the list of warnings not to be turned into errors for the gcc
analyzer will need to be updated every time we change version, i.e.
again every two years (otherwise the build-gcc job is likely to fail
when checking the compiler during configuration).

Closes: #51

Jobs and inheritances are starting to pile up, so it's best to give
things a name that won't cause confusion.