Improve dialog color api

[st0012]

As pointed out in the comment, the code is actually a control sequence and not only for colors.

To make the dialog color APIs safer to use, we should restrict its usages and extract away the bg/fg concept from the input.

So in this PR, I made these changes:

1. The dialog_*_bg/fg_color APIs only takes and returns color names (symbol):
   • :black
   • :red
   • :green
   • :yellow
   • :blue
   • :magenta
   • :cyan
   • :white
2. Add additional dialog_*_bg/fg_color_sequence APIs to read the raw color sequences.

Example

Reline.dialog_default_bg_color = :black
puts Reline.dialog_default_bg_color_sequence #=> 40
Reline.dialog_default_fg_color = :white
puts Reline.dialog_default_fg_color_sequence #=> 37
Reline.dialog_pointer_bg_color = :blue
puts Reline.dialog_pointer_bg_color_sequence #=> 34
Reline.dialog_pointer_fg_color = :black
puts Reline.dialog_pointer_fg_color_sequence #=> 30

[st0012]

cc @nobu

[nobu]

Do you think fg and bg should be able to set separately?
The (default, pointer) x (fg, bg) combination is too much a little, I think.
And scrollbar may be too.
How about set dialog-default-color cyan:white?

[st0012]

I think having separate APIs that only take 1 argument is easier to understand. If we take 2 colors, the API name will be dialog_default_colors. But then users need to learn these implicitly:

1. They should only provide 2 colors
2. The first color is for foreground, and the second is for background

And because reline currently doesn't have its own API documentations, it'll be hard for them to learn them.
So reducing APIs will save a bit code duplication, but the cost will be transferred to the user's cognitive load, which imo is worse.

[st0012]

And because reline currently doesn't have its own API documentations, it'll be hard for them to learn them.

After thinking about it, I think the lack of documentation shouldn't affect how we design an API. So please ignore this.

With that being said, other configs don't seem to take multiple values yet? If that's true, I think it's another reason we should keep it to a single value API.

[st0012]

@nobu Let me know what you think. If you still think 2-value API is better, I'll change it.

[st0012]

@hsbt Do you think the updated API looks good?

[nobu]

Looks much better than bare integers. 😃