Sketch of idea for package to index data in etcd.  DO NOT MERGE

There are several components (apiserver, controller, scheduler) where we will want to:
- lookup an API object by key efficiently (without calling etcd).
- lookup an API object efficiently by something other than its key in etcd

This is a sketch of a more general mechanism.

Feedback of any sort welcomed.  I'm particularly thinking of @lavalamp and @smarterclayton who understand the etcd Watch interface well, which this would interact with.

Alternatives Considered:

We could write custom code for this in each binary that needs to do this.
That seems bad.

We could push changes into etcd to help us with indexing.
However, doing it in a go library allows:
- faster prototyping, without ruling out eventual contrib back to etcd
- control of memory size is responsibility of each go program, rather than etcd
- short-circuits the network path for mostly-read operations, with optimistic concurrency.


I envisioned that a etcdex.Transaction object would handle that for you.   I didn't include that in the example because I wanted feedback first on whether indexes are useful at all.

But here is what I was thinking:

tr = etcdexClient.Transaction()  

// access index A, passing tr by reference.  This records in "tr" the resource version of any resources touched by this call.

// access index B ...

success = tr.Commit(thing_to_write_to_etcd)  // Only succeeds if all referenced resources are at the lowest seen resource version.