First of all, let's init with the main procedure label (stripped of
leading/traling spaces, of mnemonic underscore and of ellipsis) as
progress status for gimp_progress_init().

Then reuse this main label for all subsequent progress updates by the
same top procedure.

Finally "pulse" the progress at each update to make it more like
progression actually happens.

This is a first experiment to see if not having progress API in
Script-Fu is fine (#12948), by having better progression defaults.

Note that I don't touch the GimpFileProcedure and children because they
are special-cased anyway. As for GimpBatchProcedure, ALWAYS is a good
default too.

Completing 57e91450

This was removed by commit 38b18de7 because this operation doesn't
exist anymore and was replaced years ago. Even though it was not wrong,
let's be over-cautious rather than not enough. What if someone had still
a binary of this old operation lying around?

This doesn't cost much to keep it in the list, so let's just do it (with
a comment to still document it doesn't even exist anymore).

Since the move of GimpUnit from some weird int/enum mixed type into a
proper object type, this was not usable anymore in Script-Fu.

Functions like (gimp-text-layer-new) were therefore broken. It now works
again.

Even though the libgimp wrapper has annotations, it is still possible to
pass a NULL font through, in Script-Fu for instance by not passing all
arguments (and very likely in a plug-in by calling the PDB procedure
directly rather). And unfortunately this would crash GIMP when it tries
to work on the NULL font.

Let's do some sanity check!

It was first introduced in 131834d3 but was incomplete.

The previous code was inconditionally patching all the lang files, even
the ones which we don't use. Let's fix that using the "langs*" arrays.

Now, we can use whatever variable we want from 'config.h' with its
value, unlike the previous code which was hardcoded and did not
worked at all for variables with custom values like GIMP_RC_VERSION.

(Note: there are still work to do with Inno scripts)

Also, fixes CUSTOM_GIMP_VERSION format.

It was caused by GTK finding host's canberra or others modules, which
is goappimage fault: https://github.com/probonopd/go-appimage/issues/332

This bug will remain if the distro have some uncommon module (e.g.
appmenu, colorreload), since we don't ship them.

Closes #12937

Without this, we cannot set NULL (or equivalent, such as None in Python
3) when calling these functions in bindings.

In 9e8499bb, we forced image and drawable
previews to be 8 bit integer for compatibility.
However, this affects image previews when
in higher precisions, leading to banding
and other conversion issues.
Since the color space invasion, the original
problem should have less of an impact
as GIMP now handles conversions between
profiles much better. Therefore, we will
just grab the existing format for Grayscale
and RGB images, rather than forcing a
precision change to 8 bit.

4b15d3d6 showed that the script was imperfect in that point

As discussed on IRC these ops mostly duplicate other gegl ops and
have some shortcomings: range and gui-range, among other things,
are currently not supported. This causes some issues changing values
of parameters in GIMP, see e.g.
gegl#403

Since they bring nothing new, and have issues, we will blacklist them
from the GEGL tools interface in GIMP, at least until they have
better support in GEGL.

After discussing with NikcDC and Wormnest on IRC, we agreed that maybe a
default of being sensitive when one or more drawables are selected seems
better, since the run() signature now has an array of drawables. So most
plug-in developers will consider the case when there are several
selected drawables as an obvious possible case.

And if someone really doesn't want to handle this case, they can always
set the sensitivity mask explicitly.

In particular, when setting a sensitivity mask but no image types, the
procedure was always sensitive.
Also make gimp_plug_in_procedure_get_sensitive() more robust.

This is markup format where the asterisk has some special meaning.

Resolves #12854
Previously when loading filters, we used gimp_drawable_filter_apply ().
If there was also an active selection, it affected the recreation of the filter
and distorted the display.
This patch switches to using gimp_drawable_filter_apply_with_mask () so
that the filter's mask is always used instead, no matter if there is an active
selection or not.

gegl:pack replaced gegl:hstack almost 5 years ago, but the blacklist
for not showing it in our list of ops in Gegl tool was never updated.

Since Pack is also causing issues in GIMP, see #12890 and #12902,
let's update the blacklist add it there and remove the old gegl:hstack
that has been removed from GEGL.

Following e653535e

The meson-generated 'compile_commands.json' file added by 793c9588 shows an
assumption that we are building in-source, and assumptions are not welcome in
this general file, according to Jehan comment: !1021 (comment 1801018)