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
I suppose it's just an OSX thing, but it does look sloppy. I'm fine with improving later if an issue arises. If you do, numer and denom are 32 bit unsigned values, so the remainder term above would never overflow if you take care of casting to 64 bits first.  Apparently this is mostly just 1 these days (numer == denom) according to the source in the boost chrono library.