Add Uchar module to the standard library.

As I already made clear in previous discussions on the `caml-list`, I find that OCaml's current support for Unicode is *outstanding* (au propre comme au figuré). 

I don't think introducing a Unicode string data structure and a corresponding syntax for literals would be a good thing do to. Since, if one wanted to that in a *correct* and *useful* way, it would entail importing a good deal of the Unicode processing machinery (e.g. normalization) in the compiler and I really think it's better to leave that outside the compiler. Unicode processing can perfectly be left to a set of modularized, external libraries. I also think it's actually a good idea to proceed that way as libraries are in a better position to evolve with the standard (e.g. newly encoded characters on Unicode standard updates may imply changes to normalisation results and would entail updates to the compiler).

There is however one thing that I really find missing to get *utterly excellent* Unicode support in OCaml: an abstract datatype, *in the standard library*, to represent an Unicode scalar value (by abusing terminology: an Unicode character). An [Unicode scalar value](http://www.unicode.org/glossary/#unicode_scalar_value) is simply an integer in the ranges `0x0000…0xD7FF` or `0xE000…0x10FFFF`. 

Such a data type would allow independent libraries dealing with unicode characters (e.g. [`ulex`](http://www.cduce.org/ulex/), [`camomile`](http://camomile.sourceforge.net/), [`uutf`](http://erratique.ch/software/uutf), [`uunf`](http://erratique.ch/software/uunf), [`uucp`](http://erratique.ch/software/uucp), [`uucd`](http://erratique.ch/software/uucd)) to interchange data without relying on `int`s and as such strengthen the abstractions and guarantees a bit; avoid documentation warnings blabla that the given `int`s need to be in the above range, avoid needless (re)checks if data flows among modules, well you get the idea, the basic advantages of data abstraction...

This proposal simply adds such a minimal data type along with a few functions which by themselves don't do much except integrating with the standard library; doing real Unicode processing is left to external libraries, as it should be.

One question is whether a `Pervasives.uchar` type equal to `Uchar.t` should be introduced (not part of this proposal).  I don't think it's essential, it could be a nice touch though. 

On Thu, 10 Jul 2014 03:24:22 -0700, yallop wrote:
> 
> It seems that inlining works fine with external in the .ml file and val in the
> .mli file. [...]

Indeed.  Can it be confirmed it works in all cases?  Is it a recent improvement?  In addition to me remembering otherwise (which does not have much value), the interfaces of stdlib use "external" in the .mli — why if it not needed?