Finish KV client Prepare/Flush; refactor client for simplicity.

This change brings full functionality to client Prepare/Flush
functionality, meaning parallel querying and updates are possible.
This requires unpacking a Batch request on the coordinator and
sending the constituent requests in parallel using goroutines.
I expect further improvements here, in particular, grouping commands
by range and sending those as batches all the way through, but
that'll require some more refactoring and remains down the road.

This change also removes the BeginTransaction command. Instead,
it's now handled seamlessly as part of the first call which goes
through the txn_sender. The advent of the prepare/flush concept
means that a transactional client no longer has to support multiple
goroutines which added a lot of complexity and required the
BeginTransaction command.

There's been a dramatic simplification of the client by doing two
things:

  * Always return a fully updated transaction with the response
    for calls which specify a transaction with the request. This
    allows us to move the priority and timestamp updating to the
    server. The client now only needs to update its transaction
    with the one returned with each response.

  * Move retries due to write intent and write-too-old errors to
    the server. This eliminated the "single-call-sender" and also
    the retry loop in the "txn-sender". Besides simplifying the
    client, this also eliminates a round-trip when resolving an
    intent on a write--I believe this is a significant
    optimization for the common case.

    We are able to move this retry logic into the server (in
    storage/store.go) because I realized that we could simply
    not write response to the response cache for these retryable
    errors. Because there's nothing written, the server is
    completely free to retry (and the client too!) without any
    chance of the client seeing both error and success on
    successive retries.

I also got rid of the increasingly-complex implementation of a
coordinator-like db_test in storage/. Instead, I moved the store
tests which require transactions (to do splits) into a new test
package, storage_test, so we can just use one implementation of
the coordinator (this is what keeps track of intents and cleans
them up).
Is the client's backoff still relevant here, or is the retry entirely contained within the server?