Support non-UTF-8 character sets

[StefansM]

This commit modifies cpipes to use iconv to convert the internally-encoded pipe character lists, which are in UTF-8, to the user's locale (#9). As a bonus, it includes functions to convert from the user's locale into UTF-8, so it is now trivial to add custom lists of characters.

The implementation details are described in the comment at the head of pipes.c, so I won't re-hash them here.

As an example of this in action, here is the previous version (before this commit) running in urxvt in a GB18030 locale:

Very matrix-esque, but not what we're looking for.

After this commit, it looks like this, as intended:

There are some problems with this, which I think are mostly caused by multi-column characters. For example, xterm is still quite broken:

Interestingly, increasing the number of pipes fixes some of the alignment problems in xterm:

This leads me to think it may be related to ncurses' local move optimisations, as having two pipes will mean ncurses prefers to use cup rather than local moves like \b\b\b. I don't know whether the fault lies in ncurses (unlikely), terminfo (possible) or xterm (possible), and I don't care nearly enough to find out.

This commit also adds a unit test for the locale conversion. I've included an update Travis CI config that runs the unit test using prove as a test runner, which should be present on most dev machines.

[livibetter]

I found the results from non-UTF8-unsupported st and tmux interesting:

• xterm/tmux:

  
  (strangely, it looks like a maze game.)

• st:

  

• st/tmux:

  

---

Nice work by the way.

[StefansM]

@livibetter, it looks kind of cool -- definitely going to need to add the option for custom pipe characters. Happily, that's made much easier by this PR.

I'm not fully satisfied with this commit for a couple of reasons:

1. The crude character parser doesn't understand combining codepoints or zero-width codepoints.

2. It's broken on xterm in non-UTF-8 locales.

Point 1 isn't really an issue: this isn't the next LaTeX, so having some constraints on the allowed input is acceptable.

Point 2 is more frustrating, but in practice anyone using a non-UTF-8 locale is going to be used to weird character-encoding errors. I'm not even sure if xterm is supposed to support non-UTF-8 locales. After a bit of time narrowing down the problem, I discovered that xterm resizes each character cell after it has been written to by a multi-column character.

So, if on line one you write some multi-column characters and do nothing to line two, the column numbering looks like this:

1 2 3 4 5...
123456789...

Then, if you write multi-column chars to line 2, it resizes the cells!

1 2 3 4 5...
1 2 3 4 5...

It might be possible to hack around this, but I don't think it's possible to do so in a portable manner, unless there is a weird_multicolumn_resizing terminfo entry I'm missing. I think it's more likely that xterm just doesn't support non-UTF-8 locales, though I can't seem to find a definitive yes or no.

TL;DR: I'm merging this :)