CDK-190: Make xquery and xslt commands compatible with woodstox-3.2.7
add test and benchmark for Saxon lookup performance on large join tables
better naming
add some metrics constants
CDK-87. Add cdk:help Maven goal.
CDH-14971: Using jvm.memory.heap.used instead of jvm.memory.heap.max in test to work around an Ubuntu issue
Remove statements that are no longer true from reference guide.

Also fix typos, update interfaces that have changed, expand coverage
of Hive/HCat, and introduce Parquet.
Add documentation for dataset repo URIs to ref guide.
Improve testing for one case of schema evolution.
Add test for schema evolution case of a removed field.
Fix a few javadoc warnings and unused imports.
Fix compile error in tests.
performance enhancement
Initial commit of the core HBase Common libraries into the CDK. Instead of trying to integrate
these interfaces with the data-core package, I'm keeping them all segregated in their own module
until we figure out what we want to expose.

The cdk-data-hbase module provides interfaces for reading, writing and updating typed records to
and from HBase. This initial implementation supports Avro records for both the byte serialization
and in-memory representations. The avro implementation is in the com.cloudera.cdk.data.hbase.avro
package.

Features include ordered keys, full control over how schemas are mapped to rows that is familiar
to users of popular ORMs, familiar DAO interfaces, Avro schema management and migrations, and
optimistic concurrency control.

Features coming soon to the CDK include MR input and output formats and Pig support.
Removed the transactions related code that came in the initial import. The initial import
only included the tx code that was required to construct Daos and related classes. This
commit removes all of those dependencies, and the transactions package altogether, as we
don't want to include this in the first CDK release.
Added a test for Scanner Filters using the Avro implementation to the hbase module.
Added unit tests for the Avro Memcmp encoder and decoders that handle
ordered key serialization in the hbase module.
The type of java String object avro uses in records is configurable. This includes
keys of Map fields. When using keyAsColumn prior to this commit, the keys of map
fields were always java String types. Now, the type of String used is inherited
from the schema definition. This makes records consistent with how avro would
work against other storage backends.

One of the implications to enabling this capability is the addition of two new
abstract methods on the EntitySerDe. These are:

serializeKeyAsColumnKeyToBytes
deserializeKeyAsColumnKeyFromBytes

These methods should be overridden by EntitySerDe implementations such that
they serialize and deserialize the keyAsColumn keys according to that
implementation (as opposed to just bytes as was being forced before).
Excluding HBC from Rat check while I work though integrating HBC into the CDK.
Major refactoring of the SchemaManager (previously known as EntityManager) subsystem.
The SchemaManager no longer creates entity mappers. It now only provides schema
metadata querying, schema creation, and schema migration.

The schema management is now in a package called com.cloudera.cdk.data.hbase.manager

The sole implementation of the SchemaManager interface, DefaultSchemaManager, is not
tied to any particular schema parsing implementation. In fact, it will construct
the appropriate schema parser indicated by metadata on the managed schema record.

It's Dao implementations responsibility to construct entity mappers from the
SchemaManager's schema values. The Avro dao implementations construct a new
VersionedAvroEntityMapper which has the ability to read rows of varying schema
versions.

The ManagedSchema record now contains metadata about the schema parser to use,
and the key and entity serdes rows are persisted with. The SchemaManager uses
the schema parser metadata to construct the appropriate schema parser. It's the
Dao's responsiblity to construct the the appropriate key and entity SerDe
implementations indicated in the ManagedSchema record. The current Avro
implementation doesn't do this today since there is only one, but it's trivial
to add this in when needed.

EntitySchema implementations, like AvroEntitySchema, now have methods that
indicate whether it's legal for one EntitySchema to migrate to another. This
logic is no longer in the SchemaManager.