quadblitter emits inefficient encoding of opaque/blended data

[dankamongmen]

See comments in #1065 for background. Load up data/warmech.bmp using notcurses-view -s none -b quadblitter. This is most easily seen in the 7th row in the right orange section. There are clearly cells which are all orange (there are only four colors in this bitmap, so it's not a slight RGB difference or anything). Yet the corresponding emitted EGC is an ▀, suggesting we're writing a U+2580 UPPER HALF BLOCK followed by equivalent upper and lower colors. This is unexpected. The most efficient encoding would be a U+0020 SPACE with the proper background color (the latter only if necessary).

▐▐▀▚▀▜▙▚▌▟▚▀▀▜▙▀▙▙▀▌

the halfblock blitter emits

▀ ▀▀ ▀▀▀▀▀▀ ▀ ▀ ▀▀▀▀

with efficient spaces where expected.

Note that the resulting render is still correct; it is merely inefficient (and possibly interacts poorly when under other planes; see #1065).

[dankamongmen]

OK, yes, this is pretty clear when you take a look at quadrant_solver() and quadrant_drivers -- no space is going to be emitted from them. A fully transparent cell ought, however, result in a NUL emission (transparency). hrmm.

[dankamongmen]

We now emit a space when all four quadrants are equal. The same row as before now rasterizes as:

▐▐ ▌▀▙▚▙▐ ▙ ▜▛▀▜▌

this seems correct. It has slightly improved the problems of #1065, but not completely solved them.