The previous code loaded all the frames into memory, which causes a memory
and CPU explosion when a large GIF was loaded.

From the existing code:
/* The below reflects the "use hell of a lot of RAM" philosophy of coding */

The updated code now generates each image on demand by storing the compressed
data and decompressing and combining with the last image. This uses more CPU
than the old method, but allows arbitraritly large GIFs to play.

The stop_after_first_frame hack that worked around this is no longer required
and removed. This hack didn't work for progressive loading.

If a GIF was played with frames out of order (e.g. in reverse) this would be
quite slow, as repeated rendering would occur. This seems unlikely in the
GIF use case but if it was a problem storing some key frames that would
normally be discarded would reduce this while not using too much memory.

A render cache could also be helpful in making a CPU / RAM trade-off for
small repeating GIFs that have few frames.