meson: use an autotools compatible compatibility_version/current_version on macOS

See merge request !23

Use the same versioning scheme as libtool did with the autotools build.
Otherwise switching gdk-pixbuf from meson to autotools makes all libraries
linking to it fail since the version is too low.

Workaround to install modules with .so suffix on osx

See merge request !19

queryloaders: add missing include for OSX when using relocations

See merge request !18

The old autotools build system was create .so files instead of dylib
and G_MODULE_SUFFIX does not take into account dylib suffixes so
we should at least for now use .so until we have a better api to
use than the one provided by gmodule.

io-png: Fix various minor error handling bugs in the begin_load implementation

See merge request !16

build: Include gdk-pixdata.c when building GdkPixbuf-2.0.gir

Closes #92

See merge request !17

After the split, this wasn't included here. We need this file because
it contains the annotations for gdk_pixbuf_new_from_inline - without
those we generate broken introspection metadata.

Closes #92

Neither png_create_read_struct* nor png_create_info_struct can trigger
a longjmp out of libpng. That's only documented as being possible with
png_set_progressive_read_fn, even though, currently, it does not.

The documentation [1] is being a bit simplistic when it says:
  "... you will need to update the jmpbuf field every time you enter a
   new routine that will call a png_*() function"

On closer look, the documentation for png_create_read_struct* [2] and
png_create_info_struct [3] clarify that they return NULL on error and
don't longjmp. This is borne out by the libpng code, comments and
examples.

In light of this, the assumption that the error callback would set the
GError when either png_create_read_struct* or png_create_info_struct
fails is wrong. These functions can only fail if there was a request
to allocate an absurdly large amount of memory that exceeds one of the
limits encoded in libpng; or if the memory allocator returns NULL; or
if there was a ABI mismatch caused by compiling and running against
incompatible libpng versions. All those are either programming or
integration errors or something extremely catastrophic - normally one
wouldn't bother handling them as run-time failures. However, since the
libpng documentation repeatedly mentions that the return value from
these functions should be checked, it's wise to do so.

The current location of the setjmp is confusing to the reader because
one can be misled into thinking that there's no need to check the
value returned by png_create_info_struct, or that a failure will lead
to the error handler and a longjmp. It's better to move it closer to
the fallible png_set_progressive_read_fn.

Fallout from e8d0d8ed

[1] http://www.libpng.org/pub/png/libpng-1.2.5-manual.html#section-3
[2] http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Desktop-generic/LSB-Desktop-generic/libpng12.png.create.read.struct.1.html
[3] http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Desktop-generic/LSB-Desktop-generic/libpng12.png.create.info.struct.1.html

!16

png_destroy_read_struct is safe against both a NULL png_infop and
pointer to a NULL png_infop.

Fallout from e8d0d8ed

!16

If lc->png_info_ptr is not NULL, then not passing it to
png_destroy_read_struct will not release some resources.

Fallout from e8d0d8ed

!16

Use @basename@ instead of @filename@ for reproducible builds

See merge request !15

Whilst working on the Reproducible Builds effort [0], we noticed [1]
that gdk-pixbuf could not be built reproducibly as it includes the
absolute build path.

The glib-mkenums documentation recommends using @basename@ over
@filename@ for this reason [2].

 [0] https://reproducible-builds.org/
 [1] https://bugs.debian.org/908309
 [2] https://developer.gnome.org/gobject/stable/glib-mkenums.html#id-1.5.2.5.4

Speed up saving PNGs by skipping a null transform

Closes #90

See merge request !14

Calling png_set_shift to set the number of significant bits of input
triggers a transform operation inside libpng which shifts bits around,
even if it's a null operation of 8 bits to 8 bits.

I measured this slowdown as about 30% of total saving runtime on a
large 7680x2160 screenshot.

In addition, only 8 bits per channel are supported in gdk-pixbuf so
this is never actually needed in practice...

Skipping the png_set_shift call altogether doesn't change output and
speeds it up nicely.

Fixes #90

Ensure that building loaders.cache depends on modules

Closes #88

See merge request !13