24bit color support - first pass
I'm opening a PR for this fork, so it doesn't get lost.
There's a lot to talk about in regards to this, but I'll do a write up later. There's some really good optimizations around loading true color ansi and xbin, so that alone might be worth backfilling if this doesn't move forward.
Exporting to utf8 also now has the ability to do 4, 8, or 24bit colors. I have it defaulting to 24bit colors, and there's no interface to change it at the moment. 8bit color uses the 255 that are possible (and does a downsampling of any 24bit color), and in all other cases we only use the max we need to. Meaning that if the color is in the first 16, we don't use a 24bit color sequence for it and use the shorter ESC[38;5;15m style vs. the longer 24bit sequence of ESC[38;2;255;255;255m.
Loading and saving of an ansi with true colors also now works. So if you load an ansi with true colors in it, you will be able to see those and manipulate them. Upon saving they are written out as needed as well. An artifact of this is that colors that aren't used won't be persisted and are cleaned up if you close/reopen the file.
Things that are not yet considered:
- A bunch of cleanup.
- The server hasn't even been looked into yet.
- There are a couple UI elements and behaviors that are likely not working properly.
- There needs to be a restriction of the UI elements based on the file type you have open, as well as warnings and selections of how to handle additional colors when moving between file types.
awszome