use t=z with kitty 0.21.3+, and eliminate auxvecs entirely

[dankamongmen]

We have potentially hundreds or thousands of cells in a single graphic. In the kitty animation paradigm, we have to duplicate the entire image to use as potential rebuild data (though see kovidgoyal/kitty#3809, which would invalidate this entire issue). Rather than creating one block per cell, just create a single allocation of the sum size, swizzle to linear block form, and store indices into this block (or pointers, whatever). This collapses thousands of decently-sized (hundreds of bytes) allocations into a single large allocation.

Even if we get the t=z capability in Kitty graphics, we'll want to do this for versions between 0.20.0 and whatever version gets that.

[dankamongmen]

it looks like we got kovid's blessing for our proposal in kitty 3809, so do this if it's trivial, but otherwise invest effort in our proposed extension, and prepare a kitty PR.

[dankamongmen]

kitty 3809 got implemented for 0.21.3, so i think we can throw this on history's rubbish heap. let's instead move to take advantage of t=z posthaste.

[dankamongmen]

hrmm, it's not working as i would expect, at least not how i'm driving it thus far...if i leave the redraw out entirely, and run statepixel, we get what we would expect -- the graphic is eliminated one cell at a time. if i then turn on the t=z redraw, we get a real mess.

[dankamongmen]

so i've got the rebuilds working, but we're seeing problems on statepixel with both the old and new animation, though it works in master. so clearly we've introduced some kind of failure there; hopefully, upon getting it resolved, we'll have a complete solution here for both 0.20.0--0.21.2 and 0.21.3+.

[dankamongmen]

ok, we've got it working now! we just now need shift kitty_blit_animated() over to kitty_blit_selfref(), which right now is not working, but that ought be pretty obvious. the hard part is done!