Implement Replica RequestVote{Request, Response} handling and elections

[danburkert]

This PR implements elections for Replica, and further solidifies the Replica API. As expected, it's relatively straightforward to test Replica with the new organization without having to worry about network vagaries.

One decision I've made with the Replica API is that if any method might require a message to be sent to remote Replicas, then the method takes a message builder of the appropriate type, for instance:

    /// Apply a request vote response to the Raft replica.
    ///
    /// # Return
    ///
    /// Returns `true` if the provided AppendEntriesRequest should be sent to every peer cluster
    /// member.
    pub fn request_vote_response(&mut self,
                                 from: SocketAddr,
                                 response: request_vote_response::Reader,
                                 message: append_entries_request::Builder)
                                 -> bool;

The main motivation behind passing in the message to be built up instead of just returning the message, is that with this API we can service requests without any allocations. If the message were to be returned, then it would necessarily need to be allocated. Instead, the Server component can keep a message pool and pass in messages out of the pool. Obviously this is an optimization and isn't worth implementing yet, but we should plan for it in the API.