Expose schema and htable objects in integration tests.

Also change the contract of `.schema`: to pass an inline schema, put
it in a let and pass the let name (as a symbol) to `.schema`.
Families validate that qualifiers can be unambiguously identified.

Askari types are already forward-decodable in isolation, assuming the
decoder is aware of the type.  A decoder that needs to infer the
type can only do so under special circumstances.

A sufficient (but not necessary) way to establish that circumstance is
to require the space of possible types include identifying constants
in such a way that the encoding can only be decoded one way.

A leading disambiguating constant would do this:

    [a, i8]  # Any encoding can decode only to at most one of these
    [b, i8]

However that constraint is maybe a little too tight.  A disambiguating
constant after  a shared prefix of arbitrary, packed type components
would also be sufficient:

    [bytes, a, i8]  # These are also mutually exclusive
    [bytes, b, i8]

This is what we enforce here.
How'd that get there?
Document a landmine.
Here's Relation and Cell.

`Cell`s wrap QualifierSchemas and offer encoding/decoding operations.

`Relation` wraps a built-in HBase client (`HTable`) and offers typed
crud operations for rows within a specific relation.

Since we didn't want to make proxy objects for all the various bits of
their client API, we just allow users to create, modify, then invoke
"operation" objects such as `Get` and `Put`.  The wrapping methods
deal with encoding/decoding ruby objects to binary form.

In truth clients could exploit the exposed encoding methods and never
use `Relation` to produce such operations.  On the other end, common
methods on operations such as including families, qualifiers or
values are exposed off of `Cell` as "double-dispatch" methods.  These
merely accept an operation, perform some codec & delegate to the
operation.

We currently support put, get, scan, check_and_put and
check_and_delete.