Better Sixel Encoder Tracker

The uniform quantization of SixelEncoder is "OK" when you have 1024 colors, but not really OK with smaller palettes. With notcurses' recent work on an octree implementation there is a lovely example to look at. I'm unlikely to be able to get that fast, but faster would be nice. More importantly, prettier: I should be able to at least match a basic median-cut quality, even if it's a tad slower than uniform.

This issue will track HQSixelEncoder's progress. Goals:

• Encode with transparency.
• Direct map colors when there are more registers than required colors.
• Command-line app to create images without loading the whole UI.
• Median-cut -- maybe as an intermediate step -- for better quality.
• Octree for highest quality and best speed.
• Before/after image analysis for speed and quality.
• Pluggable vs original ("legacy") SixelDecoder (jexer.ECMA48.sixelEncoder={legacy,hq})
• Expose 4/8/16/32/64/128 palette size for HQ on UI and in docs.
• Make HQ default.

Some of the things to look out for:

• How much faster can HQ be compared to legacy? Answer: a LOT faster, even with image population analysis.
• Can heuristics on the image type help with picking the right quantizer? Or would one fast one be best in practice?
• Can the Floyd-Steinberg dithering be improved too? Or made pluggable?
• How does it look with horizontal strips vs full-size images? Will there be visible artifacts at the cell boundaries due to the different palette selections? Answer: Yes, there will be. But it's not too bad.
• How many strips in practice will be direct map? E.g. I expect all VT100 double-wdith/height and CJK/emoji to be able to go direct map -- most should just be two colors. Answer: As expected, CJK/emoji and VT100 double-width/height use very few colors and will quantize with direct map. It also exposed the image cache as another bottleneck, so now the cache is height * width / 2.
• How much can I gain by reducing to 256 registers by default, which is what most terminals are supporting out of the gate? Answer: a lot of performance, and with median-cut at the least far better image quality.

EDIT: Chafa has some really neat optimizations. Given that XtermDOOM's big bottleneck is encoding, I should see if there are optimizations I can take from both notcurses and chafa in HQ's future "best" encoder.