Implement new approach to integrity checking/syncing

This commit completely changes how riak_ensemble deals with backend
data loss situations.

Traditionally, once data was committed to a given backend, riak_ensemble
assumed the data would never go missing. Of course, this is invalid
assumption so the notion of backend trust was previously added to
riak_ensemble along with the notion of backend syncing. Untrusted peers
were required to sync with a majority of peers to become trusted. What
exactly syncing meant was a backend-specific detail.

While this handled certain cases of data loss scenarios, it was far
from perfect.

First, it assumed backend syncing was valid. For the Riak K/V backend,
this was not true. The K/V backend relied upon AAE exchange which is
was never designed to be 100% authoritative.

Second, as an optimization, we only checked a peers trust at peer
statup time (or after a backend specific process crashed). This
does not help if a backend loses data while running in normal
operation.

This commit completely removes the notion of backend trust and syncing
from riak_ensemble. Instead, riak_ensemble now implements an embedded
integrity checking protocol based on self-validating hashtrees (using
the new synctree module).

Writing of keys now inserts appropriate metadata into this hash tree,
which is always validated against the keys when read. The synctree
is considered the authoritative source. If the backend disagrees, the
data is considered corrupted and is repaired from data on other
replicas.

Like before, peers that restart are considered trusted and must do
a synctree exchange with a trusted majority (which can include more
than a simple quorum during byzantine situations). This establishes
the initial trust of the synctree at peer startup. However, since
the synctree is self-validating, every operation that touches the
tree validates the traversed path. Thus, any corrupted to either the
on-disk or in-memory components of the synctree will be detected,
causing the tree to once again become untrust and require a new
round of syncing with a trusted majority.

Thus, as designed, a given peer is always able to validate the
entirety of its backend data against the synctree metadata, as well
as validate the synctree itself and repair it via exchange with
sibling replicas as needed.
Hack around buildbot's use of ./rebar eunit