Fallback to 256color if COLORTERM != truecolor

[tompng]

Face supports hex color '#aabbcc' but some terminal does not support truecolor. (example: macOS Terminal.app)
This pull request adds fallback to 256color if ENV['COLORTERM'] is not 'truecolor' | '24bit'

About 256color

0..15 is standard color and high intensity color (this color table is customizable by terminal emulator's config)
16..231 is 216 color (r,g,b each 6 steps, 6**3 == 216) This pull request uses this part.
232..255 grayscale 24step. This pull request does not use this part event if the specified color is gray.

Each R,G,B in 216 color are 6 steps, [0, 95, 135, 175, 215, 255]
In ruby code, steps are [0, *95.step(255,40)]
when value > 95, color index can be calculated by 1 + ((value-95)/40.0).round or in short, (value - 35) / 40

COLORTERM env

Many tools uses ENV['COLORTERM'] == 'truecolor' or ENV['COLORTERM'] in 'truecolor' | '24bit' to check if truecolor is supported.
https://github.com/search?q=COLORTERM&type=code

Some terminal emulator does not set env COLORTERM even if it supports truecolor. (example: Windows Terminal)
To enable truecolor without COLORTERM env, I added Reline::Face.force_truecolor

Reline::Face.force_truecolor
Reline::Face.config(:foo) do |conf|
  conf.define :bar, foreground: '#123456'
end
# Reline::Face.force_truecolor # Writing here is also ok. It will regenerate escape sequences for truecolor

[hasumikin]

In my environment (Windows terminal | WSL2 | Ubuntu | bash | tmux), $TERMCOLOR is not set, and $TERM is screen-256color.
However, truecolor actually works (see the green gradation in the screenshot).
This means we can not use environment variables to determine if truecolor can be specified or not.

My suggestion is that the #sgr_rgb_256color should only work if the user has explicitly set the Reline not to use truecolor.
Just a casual idea but for example:

Reline::Face.truecolor = false

[hasumikin]

I'm fine