Fix numerous issues with leader leases

This pull-request builds on top of #37, so I've made the pull-request against that branch in order to keep things clean for review. After that branch merges and this review is complete, I'll open a dummy pull-request against `develop` for the final Bors checking/merge

---

By design, `riak_ensemble` uses leader leases which enable the leader to reply to read requests without contacting other peers in the ensemble.

This is similar to the design discussed in "Paxos Made Live" [1].

To safely use leader leases, a consensus protocol must:

1. Use strong leaders. A new leader should never be able to be elected while followers are supporting an existing leader.

2. Ensure that no peers (current followers or otherwise) can be become a leader before the current leader's lease expires.

The protocol used by `riak_ensemble` supports strong leaders, thus satisfying the first condition.

The second condition is challenging, because there are very few guarantees one can make about system clocks; and even fewer that one can make between clocks on different machines.

This commit hardens the leader leasing logic in `riak_ensemble`:

- Leases are now explicitly tracked (rather than just implicitly tracked as part of the leader tick/step_down transition).

- Worker processes now check that a lease is still valid after performing a read (rather than just before). This ensures that slow reads that complete after a lease expires are rejected.

- The new lease tracking logic verifies a lease against both Erlang corrected time [2] as well as against the OS monotonic clock. This is the strongest guarantee we can provide without special clock hardware (eg. GPS clocks).

- Users can now set `trust_lease = false` to force `riak_ensemble` to never trust leases and always perform quorum operations.

- A new quorum operation was added (check_epoch) that solely verifies the legitimacy of the current leader. Previously, not trusting the lease performed a full quorum read which is unnecessary. There is no reason not to trust the leader's local data if the leader is legitimate.

[1] http://dl.acm.org/citation.cfm?id=1281103
[2] http://www.erlang.org/doc/apps/erts/time_correction.html

/cc basho/riak#536
The leader dosen't block, this is being performed in an async FSM worker.

This code path  is used both when using leases and when not (eg. user set trust lease to false). Remember, leasing is just an optimization.

Without leases, the correct/desired behavior is local leader read + quorum epoch check. As explained in the commit message, quorum reads are unnecessary - if the epoch is valid, the leader has enough info locally so let's not burden the followers with useless read I/O.

Leasing is then just an optimization that uses the same code path. If lease is trusted and valid, skip the quorum epoch check. Otherwise, perform as usual.