Updating Unicode support

[Eric Pruitt <eric.pruitt@gmail.com>]

NOTE: When I first started writing this email, I didn't realize musl's
Unicode property table had recently been updated, but I noticed
<https://git.musl-libc.org/cgit/musl/commit/?id=c72c1c5> when I was
looking up commit IDs to cite. I'm leaving most of the verbiage below
unchanged since I think it adds useful context.

The Unicode property data used by musl has not been updated in quite
some time, and due to changes introduced in recent publications of the
Unicode standard, musl's width data is incorrect for many symbols --
notably emoji. This can lead to rendering glitches in terminals when
some applications are not built with musl; for example, my terminal
emulator is dynamically linked against a version of GNU libc that
supports Unicode 9 (released June 21, 2016) whereas musl's table was
lasted updated in 2011 or 2012 (commit 1b0ce9a).

To resolve this problem, I wrote a drop-in replacement for musl's
wcwidth(3) implementation that uses utf8proc
(https://github.com/JuliaLang/utf8proc) as the source of truth. You can
find the code for this at
<https://github.com/ericpruitt/static-unix-userland/blob/42cbdbb/utf8proc-wcwidth/utf8proc-wcwidth.c>.
I am wondering if the musl developers would consider accepting a patch
that implements optional / configurable support for utf8proc. The
utf8proc-wcwidth.c file I linked to includes some additional code
unrelated to musl making it possible to use the file as an LD_PRELOAD
library. The LD_PRELOAD stuff would **not** be include in the proposed
patch. I'm also investigating implementing the Unicode Collation
Algorithm (https://unicode.org/reports/tr10/) for wcscoll(3); would that
be of interest?

Thanks,
Eric