Internal Versioning

## Overview

This pull request adds partial support for heterogenous versions of etcd in a cluster. This is done by deferring command creation to a `CommandFactory` on the `Store`. The `CommandFactory` is dictated by the current version of the store.

I'm submitting this pull request to get feedback on the approach. Most of the code and refactoring Are done but I just need to implement the upgrade procedure to move between versions.


## Changes

* Added `CommandFactory` interface. This is a common API for server handlers to use to create commands. It allows us to separate external API versioning from internal command versioning.

* Moved existing store commands to `command/v2`. The `v2` package contains an implementation of `CommandFactory` that creates version 2 commands.

* Changed `JoinCommand` to use a minimum and maximum version to allow a range of compatibility for binaries. This means that if a cluster is running at version 3 then a binary that supports versions 2 - 4 could join it. The cluster can also upgrade to version 4 if all nodes support it. However, the cluster would not be able to upgrade to version 5.

* Changed the `/version` endpoint to return a single integer representing the internal version.

* Removed the `raftVersion` from the registry. We don't actually use this (as far as I could tell) and it can easily change as nodes upgrade.


## Not Yet Implemented

* Upgrade cluster version. This will need to be a call to set the version on the `Store` to the maximum version of all nodes in the cluster. All nodes in the cluster will need to be available to perform an upgrade.

* Test upgrade procedure. This will be a little tough since we don't have a version 3 to move to. Upgrading from v1 will probably require that we dump to a snapshot and then start up in v2. I would doubt that v1 and v2 commands are compatible.

/cc: @philips @xiangli-cmu