Sixel implementation: Sixel parser
Part of #253. This issue is for reviewing the new sixel parser.
Taking the liberty of quoting Christian from the old Bugzilla bug:
I've looked at the sixel branch again, and while there had been a bit more work on it than what I remembered, and some of it is to start addressing some of the problems it had (i.e. the storage problem), it was done before vte really started using more C++, so it can probably only be taken as hints, not forward-ported. Plus the code style, etc.
I particularly didn't like the actual sixel parser in it; it mixes parsing of the actions and executing the actions, and therefore duplicates e.g. parsing the parameters. That should be split; the design of the main parser (parser.cc) is the model how this should look (IMO). Also the parser can't be hooked up to vte the way it used to (the branch is from 2017, and in 2018 vte got a completely new parser). I have some work planned to make it possible to hook up extra parsers (for DCS control strings), but until that's ready (not for a while), you can just parse the control string completely in ::DECSIXEL (but need to temporarily bump VTE_SEQ_STRING_MAX_CAPACITY).
I've hooked the parser back up and increased VTE_SEQ_STRING_MAX_CAPACITY on my branch, so it works now. But the parser still needs to be refactored and made style conformant.