fmt: Knuth-Plass implementation; common: add unicode char_width function

fmt:
- Implemented Knuth-Plass optimal linebreaking strategy.
- Added commandline switch -q for "quick" (greedy) split
  mode that does not use Knuth-Plass.
- Right now, Knuth-Plass runs about half as fast as greedy.
  It also inherently uses more memory.
- Updated fmt to use char_width (see below) instead of
  assuming each character width is 1.
- Use i64 for demerits instead of int in K-P, since int is
  pointer sized and will only be 32 bits on some
  architectures.

common:
- Added a support module for computing displayed widths of unicode
  strings based on Markus Kuhn's free implementation at
    http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c
- Also added support for auto-generating the width tables based on
  updated unicode charset data. This script only needs to be run when
  unicode charsets are updated. There is no reason to regenerate this
  during building.
- I'm hopeful that eventually this functionality will be in libcore and we
  will be able to get rid of it.

Closes #223 
As I traverse the words in the paragraph, I build up a Vec of LineBreaks. Each LineBreak has a pointer to its predecessor in the list, which is necessary in order to, at the end, retrieve the sequence of linebreaks that got us to this point. It's a skiplist, more or less.

So you could ask two questions:

1. Why pointers rather than references? When I create a new LineBreak, I need to refer to its predecessor in the LineBreak struct, then push that struct into the Vec. Once I've got a reference to the predecessor (which lives inside the Vec), the Vec is borrowed, and I can no longer push a new element onto it. Of course, this makes sense: if the Vec gets reallocated (e.g., when it gets extended), the reference becomes invalid. This brings up the Box.

2. Why boxes? Well, as I pointed out above, if the Vec gets reallocated, its contents (can) get moved around, which means that if the LineBreak structs live directly in the Vec, pointers to them become invalid when the Vec is reallocated. So instead, I store Box<LineBreaks> in the vec, and the pointers I generate above are pointers to *the content of the box*. This way, the Vec can realloc all it wants, and the pointers inside the list stay valid.

Note one more thing: the Vec's length is *never* reduced. Once I allocate a Box, it will live until the function returns. This is important, because it provides justification for the safety of the `unwrap{}` call you questioned below.

Thanks for the comments, by the way!