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

We're passing the full path to the shared modules, which confuses Meson.

Closes #88

A copy and paste thinko on the GDK_PIXBUF_UNAVAILABLE_IN_* macros after
2.22 generated the exact same warning for all releases after that.

This commit introduces no functional change, only an updated compiler
warning with the correct version numbers.

Group the sections that are deprecated or that defer to another library,
to ensure that readers are aware of their status at a glance.

We did not introduce any new symbol, but it's good project hygiene to
always have per-release version macros as part of the release process.

We need to use the ulink element, not the link one, for URLs.

We regenerate the types file every time we build the documentation, to
avoid missing types.

A couple clarifications of the wording in the build instruction.

Make the README a bit more helpful.

The read_pixels() method is missing a `Returns` stanza.

The read_pixels_bytes() method is missing a description.

Both functions do the same thing, so they should be documented
similarly.

Drop the conditional support on get_supported_link_arguments(), as there
have been multiple stable releases of Meson with that method.

Clarify pixels vs. bytes

See merge request !6

One needs to pass in -Dx11=false as well, for all Visual Studio builds.