See:
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=a1acd8e66b7a4ca348401f890b4f04a6ca6b7d15

gspell is not part of GNOME Core, but it's a core dependency.
In case of doubt, it's better to remove the <category>, and I don't
think it's super important after the switch from cgit to GitLab (in cgit
the git repos were grouped into different categories).

And, the less the better. Less things to keep up-to-date afterwards.

Space out a bit the XML elements, for an easier reading.

git.gnome.org has been replaced by gitlab.gnome.org, and GtkSourceView
git master/main is now for GTK 4.

So it's easier to just copy the required files locally, in the same
directory, and run the script.

I don't use them. A better way would be to have an EditorConfig file.

The less the better, when moving to another build system it's one less
thing to care about.

This reverts commit 28b7e23f.

I didn't know, but it's actually used. The generated *.pc file contains:

libdir=${exec_prefix}/lib64

This is not necessary with some other build systems.

Like how it is done in the Amtk library.
To simplify things, especially in the build instructions.

I think that function could be useful for initializing i18n, but it has
been unused since the beginning of gspell I think.

The less the better.

The GSPELL_AVAILABLE_IN_* macros were intended to be used, perhaps one
day, to have something like GTK has: to check at compile time that we
don't depend on too recently added symbols, if we need to deploy a
program on a distro with an older version of the library. Or, use
conditionally newer symbols, etc. With deprecation macros and
everything.

But I prefer not to have all the infrastructure for that in a small
library like gspell. If creating a small library involves adding lots
and lots of scafffolding, it's too much work compared to the size of the
library.