Refactor mod/lock.

## Overview

The new `mod/leader` module has a lot of similarities to the `mod/lock` implementation. Even the Zookeeper recipe is very similar. Because of that I refactored the `mod/lock` to support most of the `mod/leader` functionality. I'll still add the leader module with a simplified API in a separate pull request.


## Changes

The main change is that the lock can now be associated with a value. The value is unique so if a lock tries to request a value that is already queued for a lock then it will find it and watch until that value obtains the lock. If you lock the same value on a key from two separate curl sessions they'll both return at the same time. It's pretty cool. :)

Here's the new API:

```
# Retrieve the current value for the "foo" lock.
GET /mod/v2/lock/foo

# Retrieve the current index for the "foo" lock.
GET /mod/v2/lock/foo?field=index

# Acquires a lock (with no value) for "foo".
POST /mod/v2/lock/foo?ttl=60

# Acquires a lock for "foo" that is associated with the value "bar".
POST /mod/v2/lock/foo?ttl=60 -d value=bar

# Renews the TTL on the "foo" lock for index 2.
PUT /mod/v2/lock/foo?ttl=60 -d index=2

# Renews the TTL on the "foo" lock for value "foo".
PUT /mod/v2/lock/foo?ttl=60 -d value=bar

# Deletes the "foo" lock with the index 2.
DELETE /mod/v2/lock/foo?index=foo

# Deletes the "foo" lock with the value "bar".
DELETE /mod/v2/lock/foo?value=bar
```

The wrapping leader module can just ignore the indices and only deal with values. It's API will be something like:

```
GET /mod/v2/leader/foo
PUT /mod/v2/leader/foo?ttl=60 -d value=bar
DELETE /mod/v2/leader/foo?value=bar
```


## Other Notes

I also cleaned up the code to be more modular and I added a `lockNodes` type that wraps `etcd.Nodes` so it can access indices and siblings.

/cc: @philips @xiangli-cmu