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.
I'm guessing the distance error is an attempt to reduce the amount of error possible when reading a remote clock. This is because the round-trip delay is proportional to the maximum error of a clock reading. 

I actually include this error in the interval, and unfortunately larger errors will possibly lead to a larger ClusterOffsetInterval measurement. Practically, the heartbeat timeout currently establishes the maximum reading delay, and therefore the maximum error. Thus I think we do indirectly include the distance error through this timeout.

We might considering having the maximum error be parameterized, or at least be aware that the heartbeat timeout establishes the limit.

I don't think that the loop error is a concern, because it seems like more of a synchronization concern than an offset measurement concern. Similarly, we can't really detect something like a stratum error, and we have to assume that all nodes are already synchronized.