Allow stacking images when using unicode placeholders

[Nogesma]

Is your feature request related to a problem? Please describe.
The app I am using this for, twitch-tui, is displaying images in between text, using them as emojis.
Before unicode placeholders were available I had to keep track of the position of the text and move the images accordingly.
Now that they are available it simplifies my code a lot, but it's missing a feature I was using, stacking images by specifying a z-index.

Describe the solution you'd like
I was thinking of two possible solutions to this problem:

• Specify another image to stay at the same position of when displaying an image.
  ex: <ESC>_Ga=p,i=<image id>,p=<placement id>,z=<z-index>,b=<image id>,c=<placement id>;
  Where b is the id, and c is the placement id of the other image to "stick" to.
  This would allow to display the first image with unicode placeholders, and the rest of images with a display command.
  b and c are examples of the keys that could be used, I haven't checked if they're available.

• Join unicode placeholders with a zero width space.
  ex: \e[38;5;42m\U10EEEE\U0305\U10EEEE\U200B\e[38;5;43m\U10EEEE\U0305\U10EEEE
  This would display the image with id 42 at z-index 0 and the image with id 43 at z-index 1.
  I don't know if this one is possible.

I am not familiar with the codebase at all so I might have missed some better way to do this, please let me know.

I'm open to try to make a PR if no one is interested in doing so.

[kovidgoyal]

Your approach (2) is not feasible. The way unicode placeholders work is
that the image data is encoded in the unicode data which is stored in
cells. cells cannot store arbitrary amounts of data. Besides I think
this approach is much less flexible than (1), see below.

Some random thoughts on approach 1:

Having image placements that track existing ones is potentially do-able,
but it has some subtleties. One has to consider what happens when the
tracked image is deleted, and avoid endlessly long lookup chains and
cycles in the lookup chains. Then there will be issues with
implementation, I dont know how efficient the current way image
placeholders are stored in kitty is for having one placement track
another.

From a protocol design perspective, I don't see why this should be
limited to tracking unicode placeholder placements. It would be
generally useful to be able to say create a placement that tracks
this other placement with an offset of X,Y cells. So a complex UI
could be made of 10 different images all positioned relative to each
other, the application can move just the base one and all the rest
will maintain relative position.

So if you are interested in designing such a protocol extension I will
be happy to provide any needed guidance/review. Relevant code is in
graphics.c and gen-apc-parsers.py (for parsing the graphics escape
code).

[Nogesma]

Alright I'll start to look into it this weekend, I'll let you know if I have any questions.

[kovidgoyal]

Closing feel free to continue the conv.

[Nogesma]

Sorry for the late update, I haven't really had time lately, but I'm still working on this and I have a basic prototype working.
I might make a draft PR for you to see progress and give feedback in the next few days.

Implementation wise, I think long lookup chains are unavoidable if we want the flexibility of moving around part of an image chain (ie. move only c, d in the a <- b <- c <- d chain).
I can move most of the processing in the put_command handler, and have the base image have a reference to all the images in the chain, which would avoid having a lookup chain whenever an image is displayed.
I also found I can reuse a lot of what has been done with unicode placeholders. I can create virtual image refs for the images in the chain, and convert them to real refs when the base image is displayed.
If a tracked images is deleted, it would probably be best to have all its childs deleted too (ex: in the abcd chain above, deleting b would also delete c and d).