move Unicode width() functions to unicode_width crate

[kwantam]

This patch removes the Unicode character width functions from
libunicode. Specifically, the functions str.width() and
char.width() have been removed.

This functionality is now provided in the unicode_width crate,
available from crates.io.

Note that libsyntax and librustc_driver made (limited) use of these
functions for prettyprinting. These uses have been replaced by
code that assumes all characters have displayed width == 1.
In almost all cases this will have no visible effect on the output.

[breaking-change]

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[kwantam]

First of three PRs to push peripheral Unicode handling to crates outside of libstd.

I believe this is the only one of the three forthcoming PRs that ends up touching functionality
used in the compiler. Specifically, libsyntax and librustc_driver used width() for
pretty-printing. If this functionality is really necessary/desirable, we can either retain
width() in std (presumably behind a deprecated gate encouraging others to use the
crates.io implementation, as with rand), or pull in unicode_width as a submodule. It
seems a shame to leave a big character table in libunicode for a prettyprinting case
that will realistically almost never come up.

[alexcrichton]

Awesome! Thanks!

Some suggestions:

• Could future crates be called unicode-foo instead of unicode_foo? Conventionally package names in crates.io have hyphens in them which are auto-translated to underscores in the crate name for the compiler.
• Could this leave all the support for the functions around temporarily with a #[deprecated] tag? That should help ease the transition for users currently leveraging these functions. We should be able to delete all the support code soon hopefully!

Also cc @aturon, I'm a fan of this strategy but want to check with you as well!

[kwantam]

OK, I'm going to close this PR and open a different one that adds #[deprecated] to the functions in question.