Unicode collation.

collatejson, with this commit, supports three forms of unicode collation.

1. UTF8, strings are expected to be encoded in utf8 format and we do memcmp on
   the encoded utf8 binary.

   codec.SortbyUTF8(true) should enable this kind.

2. NFKD, canonical decomposed form of normalization. In this case, variants of
   alphabets, like the once explained by Alk below, will be decomposed into
   multiple unicode chars with combining classes. Using this kind will increase
   the encoding time of strings to NFKD binary and will increase the size
   of encoded binary.

   codec.SortbyNFKD(tru) should enable this kind.

3. Golang Collator, strings are converted into raw-key by go.text/collate
   library based on unicode standard. Refer to its documentation to learn
   different ways of controlling the collation algorithm. Using this will
   increase the encoding time of strings and will blow up the size of
   encoded binary.

Added testcases, benchmarks and updated the tool-programs as per new
modifications.

-----------------------
found these lines in Wikipedia, http://en.wikipedia.org/wiki/UTF-8

    Sorting a set of UTF-8 encoded strings as strings of unsigned bytes yields the
    same order as sorting the corresponding Unicode strings lexicographically by
    code point.

Alk's points and suggestions,

  our existing views are using unicode collation. i.e. so that stuff like
  A-umlaut sorts after A but before B. There's also different ways to represent
  certain things which unicode collation "aware" comparison functions need to
  handle. Said A-umlaut can be single unicode char and two unicode chars - A and
  some combining charatecter.

  It's a fact that icu has some bunch of tables that drive unicode-collation
  aware comparison. And that makes it one of slowest parts of index building
  AFAIK.

N1QL specifies default collation sequence as memcmp() on the native string
encoding,
    https://github.com/couchbaselabs/query/blob/master/docs/n1ql-select.md

My understanding on unicode,

   At language level individual characters and their unicode codepoint are
   sequenced in sort order.

   Problem arises when languages try to share scripts from another language.
   For instance many language use english alphabets for written script, and
   for language specific phonetics they extend with special characters.
   These characters define their own code points and this breaks the sort
   order.

   To avoid this unicode has defined decompositional normalisation, where by
   code points can be encoded using combining classes. For instance,

   $ go run tools/encode/encode.go -s "öf"
   composed: [195 182 102]
   decomposed: [111 204 136 102]
   rawkey: [23 113 22 132 0 0 0 32 0 71 0 32 0 0 2 2 2]

   Another problem is that different languages define different sort order for
   same character, like,
   Swedish: z < ö
   German:  ö < z

   Even within languages, sort order is different based on the context of
   usage.
   German Dictionary:   of < öf
   German Telephone:    öf < of

   I posted a question in golang-nuts about unicode collation,
        https://groups.google.com/forum/#!topic/golang-nuts/MyvlV4MOLHk