FLOATING_POINT options were switched off, png.h ended up with lone ';'
    characters.  This is not valid ANSI-C outside a function.  The ';'
    characters have been moved inside the definition of PNG_FP_EXPORT and
    PNG_FIXED_EXPORT. 2) If either option was switched off, the declaration
    of the corresponding functions were completely omitted, even though some
    of them are still used internally.  The result is still valid, but
    produces warnings from gcc with some warning options (including -Wall). The
    fix is to cause png.h to declare the functions with PNG_INTERNAL_FUNCTION
    when png.h is included from pngpriv.h.

to be prefixed (suggested by Reuben Hawkins).  This is work in progress that
breaks some non-configure builds.

to the background parameter of png_image_finish_read. The --background
option is now done automagically only when required, so that commandline
option no longer exists.

This is an initial version for review; the documentation has not yet been
updated.

changes some of the macro definitions in png.h, app code may need
corresponding changes.

 Because these APIs store to the png_info they can take a
 png_const_structrp now that the error routines also accept
 one of these.

Added new "png_structrp" typedef. Because of the
way libpng works both png_info and png_struct are always accessed via a
single pointer.  This means adding C99 'restrict' to the pointer gives
the compiler some opportunity to optimize the code.  This change allows that.

Previously it was disabled whenever internal fixed point arithmetic was
selected, which meant it didn't exist even on systems where FP was available
but not preferred.

changes alter how the tricky allocation of the initial png_struct and png_info
structures are handled. png_info is now handled in pretty much the same
way as everything else, except that the allocations handle NULL return
silently.  png_struct is changed in a similar way on allocation and on
deallocation a 'safety' error handler is put in place (which should never
be required).  The error handler itself is changed to permit mismatches
in the application and libpng error buffer size; however, this means a
silent change to the API to return the jmp_buf if the size doesn't match
the size from the libpng compilation; libpng now allocates the memory and
this may fail.  Overall these changes result in slight code size
reductions; however, this is a reduction in code that is always executed
so is particularly valuable.  Overall on a 64-bit system the libpng DLL
decreases in code size by 1733 bytes.  pngerror.o increases in size by
about 465 bytes because of the new functionality.

These changes alter how the tricky allocation of the initial png_struct and
png_info structures are handled. png_info is now handled in pretty much the
same way as everything else, except that the allocations handle NULL return
silently.  png_struct is changed in a similar way on allocation and on
deallocation a 'safety' error handler is put in place (which should never
be required).  The error handler itself is changed to permit mismatches
in the application and libpng error buffer size; however, this means a
silent change to the API to return the jmp_buf if the size doesn't match
the size from the libpng compilation; libpng now allocates the memory and
this may fail.  Overall these changes result in slight code size
reductions; however, this is a reduction in code that is always executed
so is particularly valuable.  Overall on a 64-bit system the libpng DLL
decreases in code size by 1733 bytes.  pngerror.o increases in size by
about 465 bytes because of the new functionality.