With the completion of #1378, our Sixel encoder seems to be working properly. It's now time to better integrate pixel graphics with the render and raster pipelines, so it's useful in Notcurses as something other than a novelty.

• we've absolutely got to get input quantized down to 256 colors, or do it ourselves, as we reject most media right now due to this constraint
• we need quantize down to a palette of 256 colors (xterm only supports 16 by default)
• always do a hard cup after emitting pixel graphics -- i think we're already doing this for rendered mode
• we need to be setting the width field correctly (we currently always set it to 1)...though i'm not sure how useful this is,
• what's up with scaling? see below
• see if we can use the DEC macro functionality to only write these things once (DECDMAC and DEVINVM)
• rigourize corner cases -- what happens if pixel is last output on frame? first? with both pixel and otherwise coming next/before?
• (updated: moved this to figure out pixel integration with the z-axis #1388) see what can be done about transparency, in both directions (pixel on top, pixel below)
• we absolutely must have some unit tests on this
• speed up the sixel encoder, which is aggressively suboptimal

with regards to scaling, currently if i run

./ncplayer -b pixel ../data/worldmap.png -k -q

in a 78x80 xterm, i get no output. if i run instead

./ncplayer -b pixel ../data/worldmap.png -k -q -s none

i get about two empty pages, with the image in the middle, with part of the right chopped off.

stretch, none, et. al. ought work for pixel like they do anything else, and this excess vertical space has got to go. i think the latter comes from creation of a n/6-row plane for n pixels going into the sixel.