Add support for colo(u)r table with first entry as transparency

[lovell]

Guten Tag, I've taken the approach as suggested in #4, ensuring the relevant disposal method is set, plus added a unit test.

I've also tested this using a botched together libvips+cgif integration and the obligatory dancing banana.

[sethify]

The banana looks great 👍

[MCLoebl]

We are looking into your PR. There are a few things that we will check to make sure it is consistent with all the other flags.

[dloebl]

Looks good.
However there are a few cases to consider:

• This PR assumes that all frames of the GIF image have FRAME_ATTR_HAS_TRANSPARENCY set, otherwise if you have regular frames (with disposal method 1) in between the resulting image might be unexpected (disposal methods always affect the next frame).
• disposal method 2 restores the used area of a frame to transparent => so in case frame B has user-defined transparency, frame A must define all pixels of the graphics (no FRAME_GEN_USE_DIFF_WINDOW optimization possible).

In order to resolve these issues some rework would be required on how CGIF writes individual frames:
Basically we cannot write frame A before we know the configuration of frame B.

Are you aware of any GIFs that mix transparent and regular frames? I would think that is rather uncommon.
From my side we can merge this and then address the above issues (I can take care of the rework).

[lovell]

For the purposes of libvips integration, making FRAME_ATTR_HAS_TRANSPARENCY and FRAME_GEN_USE_DIFF_WINDOW mutually exclusive makes perfect sense.

Rather than a frame-level setting, perhaps we should shift FRAME_ATTR_HAS_TRANSPARENCY to a top-level GIF_ATTR_... property as part of this PR?

If the attribute were to remain at frame level, it might be that the API should then allow for fine-grained control over the disposal method e.g. FRAME_ATTR_DISPOSAL_...

[dloebl]

For the purposes of libvips integration, making FRAME_ATTR_HAS_TRANSPARENCY and FRAME_GEN_USE_DIFF_WINDOW mutually exclusive makes perfect sense.

Rather than a frame-level setting, perhaps we should shift FRAME_ATTR_HAS_TRANSPARENCY to a top-level GIF_ATTR_... property as part of this PR?

If the attribute were to remain at frame level, it might be that the API should then allow for fine-grained control over the disposal method e.g. FRAME_ATTR_DISPOSAL_...

Yes, moving this flag to a GIF_ATTR.. sounds perfectly reasonable.
Transparency on a frame-level would drastically increase the complexity of the encoder, with (probably) not that much gain.