Meson build defines G_MODULE_SUFFIX to `dylib` on macOS but autotools uses `so`

We have previously touched on this at #520 (closed).

G_MODULE_SUFFIX has always been set to so because that's what autotools uses for plugins.

However, the rest of the world uses .dylib on macOS for plugins, so Meson creates plugins with a dylib suffix, and so we're stuck.

Ideally, on macOS GModule should be able to load modules that are of the form libfoo.so and libfoo.dylib.

We can't change G_MODULE_SUFFIX because that breaks the world. So we should deprecate G_MODULE_SUFFIX, and keep it at so.

Opinions begin

G_MODULE_SUFFIX and g_module_build_path are kinda broken because they have to guess a single path without accessing the disk:

Linux/BSD: https://gitlab.gnome.org/GNOME/glib/blob/master/gmodule/gmodule-dyld.c#L138

AIX: https://gitlab.gnome.org/GNOME/glib/blob/master/gmodule/gmodule-ar.c#L173

Windows: https://gitlab.gnome.org/GNOME/glib/blob/master/gmodule/gmodule-win32.c#L174

macOS: https://gitlab.gnome.org/GNOME/glib/blob/master/gmodule/gmodule-dl.c#L172

So that guesswork gets pushed to g_module_open, which has a hack to search for .la files:

https://gitlab.gnome.org/GNOME/glib/blob/master/gmodule/gmodule.c#L545

And then everyone else has to put comments about this weird undocumented behavior:

https://gitlab.gnome.org/GNOME/libpeas/blob/master/libpeas/peas-object-module.c#L111

And after all this work it's not cross-platform anyway because on macOS plugins can have dylib or so and on Windows plugins can be libfoo.dll or foo.dll, and on Cygwin they can be cygfoo.dll or foo.dll.

Danger, Will Robinson!

We should not move glib to use only Meson as the build system till this is fixed, unless we want to keep old autotools mistakes forever. The move to Meson is a good time to get consumers of GModule to move to a new API that can cover all this. See #520 (closed) for some ideas.