Added ability to measure clock offset from cluster

RPC servers and clients now both update a shared map of measured remote offsets.
Servers get this measurement from their attached clients. Servers
are given this ability because they don't always have their own client to the
remote node if that remote node has a client to them.

The server now passes a Context object to the rpc frameworks rather
than passing all 3 required fields individually.

Though the algorithm for measuring cluster offset is now implemented, the server does not yet actively measure cluster offset nor does it do anything with any offset measuring.
Let's make this method return a ClusterOffsetInterval and an error. Return an error here indicating that a majority of connected remote clocks have failed to encompass a true time for the cluster.

The caller should then log.Fatalf, dumping all remote offsets, keyed by addresses.

One other thing that occurs to me: is there any practical lower bound on the number of remote offsets needed in order to run this algorithm. Should we do it in the case of just one or two connected nodes? Seems like that still makes sense, but curious if there's some reason not to.

Also, make sure that if the cluster is just a single node we don't invoke this anyway with strange results.