[RFC] support color256 decoding, "fixes" color256 encoding

[johnnychen94]

This is an attempt to decode color256 codes, the decoding table comes from https://www.ditig.com/256-colors-cheat-sheet

By applying decoding to our encoded result, it seems that our previous encoding implementation is not ideal:

using ImageCore
using OffsetArrays

function colorwheel(sz::Dims{2}, v=1)
    # H, S
    canvas = OffsetArrays.centered(fill(ARGB(0, 0, 0, 0), sz))

    for I in CartesianIndices(canvas)
        x, y = I.I ./ (size(canvas) .÷ 2)
        r = sqrt(x*x+y*y)
        if r < 1
            h = atand(x, y) + 90
            canvas[I] = RGB(HSV(h, r, v))
        end
    end
    return canvas
end

rgbwheel = colorwheel((512, 512))
graybar = Gray{N0f8}.(transpose(repeat(range(0,stop=1,length=256),1,80)))

enc = TermColor256()
@. enc(enc(rgbwheel))
@. enc(enc(grabar))

Graybar

From top to down: Base, original, PR. None of them are ideal but the PR version is less incorrect in the sense it doesn't convert black to white...

RGB wheel

From left to right: Base, original, PR. The PR version seems quite ideal here.

ImageInTerminal visual changes

However, the encoding visual change by checking ImageInTerminal is negligible. The reason might be that we do multiple restrict to the image.

---

The test fails on ImageInTerminal because the encoding strategy is changed and references are not updated. The performance is also not tweaked.

[johnnychen94]

This can be implemented wrong here; just that this version passes the enc(enc(c)) = c test for those 256 colors.

[t-bltg]

@johnnychen94, I'm going to rework this PR in a new one (easier for me).

I remember having spent quite some time figuring out the correct rgb colors for the 6x6x6 cube in Crayons.jl (https://github.com/KristofferC/Crayons.jl/blob/417e3af6f3c28168553c662f605255b8e1fe1f14/src/downcasts.jl#L29) so I'm going to follow that.