[libpng18] [code standardisation] Use standard C attributes

[jbowler]

ISO have recently standardized a way of defining attributes based on the
ISO-C++ syntax standardised in 2011. This allows removal of the
existing compiler-specific hacks as well as compatibility with C++. The
latter is important for attributes used in the header files which
declare the libpng API (png.h and descendants.)

This also extends the attribute handling to any compliant C compiler,
not just the three with compiler specific support in the prior code.

The fix also enables removal of the highly idiosyncratic use of specific
comments to indicate "fall through" in case statements; the concept is
now supported by the [[fallthrough]] attribute.

The changes include checks to ensure that the attribute syntax is
supported by the compiler and that the specific attributes are also
supported.

The changes are detailed in these commits:

commit 51b6189
commit 8942be9

Signed-off-by: John Bowler jbowler@acm.org

[jbowler]

@ctruta a ping on this PR, it changes a number of files because ISO standardised a placement for the attributes which GCC does not accept as conforming to where GCC/MSVC attributes have to be place. I.e. GCC wants them in a different place. Consequently there's the potential for merge conflicts here if the change remains hanging.

[ctruta]

Acknowledged, thank you. Please give me another day or two, because I want to integrate my own changes to the CI scripts (so that we can have verification both from libpng16 and libpng18) and to the CMake file (so that I can expand my testing, including the cross-platform testing). I plan on releasing libpng-1.6.45 with the most recent changes, BTW.

But I won't be changing any png*.[ch] source code, so your PRs should apply cleanly afterwards, no further rebasing necessary.

[ctruta]

@ctruta a ping on this PR [...] there's the potential for merge conflicts here if the change remains hanging.

I kept thinking about this PR, as well as #572. I want to reiterate that I do want to take this stuff in, but I'd like to refrigerate it for now.

I said before that the order in which I'm applying external contributions (as well as my own changes) is somewhat chaotic, but there is at least some logic to it. We need this commit, but we need house cleaning also, and I'd like to prioritize the house cleaning first. (Better develop on the smaller and cleaner codebase.) Another thing that I'd like to have is a smaller divergence between the branches libpng16 and libpng18, at least for the beginning of the life of libpng18, because the upcoming fixes for libpng18 that will need to be applied to libpng16 will be that much easier to apply and cleaner also.

So, after I publish libpng-1.6.45, I'd like to resync the two branches, and then (when possible) to use git merge COMMIT instead of git cherry-pick COMMIT, just to keep the two branches closer to one another. Don't fret too much about merging the conflicts, for now, @jbowler. After we're (mostly) done with the above-mentioned priorities, we'll come back to this one.