HBASE-8693 Extensible data types API

This patch introduces an extensible data types API for HBase. It is
inspired by the following systems:

 - PostgreSQL. Postgres has a user-extensible data type API, which has
   been used to great effect by it's user community (ie, PostGIS). The
   desire is for HBase to expose an equally extensible data type API.
   One aspect of the Postgres data type is the ability to provide
   equivalence functions for index operations. This appears to be of
   critical performance utility for its execution engine.
 - Orderly. Orderly handles the issue of compound rowkeys by providing
   convenience classes for handling these kinds of data types. This
   influence is reflected in the Struct and Union family of classes.
 - Phoenix. The PDataType enum used in Phoenix provides type hints,
   similar Postgres's equivalence functions. These appear to be used
   during query execution for numerical type promotion.

This patch introduces an interface, DataType, along with a number of
data type implementations. Implementations based on Bytes are referred
to as "Legacy" types, implementations over OrderedBytes are "Ordered"
types. Also included are Struct and Union types, demonstrating simple
implementations of compound types. Helper classes around the Struct
implementation are also provided.

This patch does not address the type compatibility concerns expressed
by Phoenix's PDataType API (ie, isComparableTo, isCoercibleTo); these
will be addressed in HBASE-8863.
HBASE-8693 [example] Use DataType API to build regionNames

This is an example of using the HDataType classes to manage
HRegionInfo's regionName. It could probably be taken a step further to
manage the MD5Hash as a LegacyBytesFixedLength, then the size of the
allocated buffer could be calculated with
HREGIONINFO_NEW_CODEC#encodedLength() instead of by hand.
HBASE-8693 [example] KijiFormattedEntityId

Demonstrates using DataType to implement kiji-schema's rowkey
concept, FormattedEntityId.