Phs/coprocessor dsl

Here's `RegionObserver::DSL`, `::Application` and `::Runner`.

The `DSL` offers a sinatra-esque way to build up a set of coprocessor callbacks, which accumulate in a hidden, associated `Application` instance.  This `Application` will then be handed to a `Runner`, which interfaces with our java `RegionObserver` implementation to drive event dispatch.

Each kind of event (e.g. `:post_put`) registers a dispatcher responsible for invoking handlers and folding results.

We choose to imitate HBase's own dispatch rules (across coprocessors), so that multiple (say) post_put hooks function identically whether they share the same askari coprocessor instance or not.  These can be inspected in HBase source in `RegionCoprocessorHost`.

This dispatch process is nearly identical for all events, but three key facts vary between them:
 * First, some events are expected to return a value, others do not.
 * Secondly the results of some handlers are expected to be fed into the arguments of successive handlers, others not.  The identity (index) of this "pivot" argument of course varies between events.
 * Finally, some events choose to respect the `#complete` method on their contexts by terminating dispatch before later handlers get invoked. Other events ignore `#complete.`

Applications are aware of dispatch rules even if handlers are missing. This allows folding events to return the correct argument instead of `nil` when no handlers are present.

Applications can `#serve` each other for composability, and exploit modules.

`HRegionAsHTable` is a `HTableInterface` adapter for `HRegion`s. With this adapter, we should be able to use `HRegion`s from within `Relation`s (see `ExecutionContext#local_relation`).

Creator sets the `askari.name` coprocessor argument to the name appearing on that coprocessor in the schema.  This way a coprocessor can discover its own definition.

Also drop the lock/unlock coprocessor events, they're deprecated.