We definitely need to take care of currentUtcOffset, but the current
implementation was wrong: it only used it in modifying receive stamps,
thus achieving completely wrong tuples.

It's the receive function that must apply the utcOffset, or not,
according to how it timestamps frames.  Similarly, it's the time
setting functions that must use utcOffset, or not, according to whether
the time is utc (e.g.: unix) or tai (e.g.: wr).

So this just removes a wrong attempt, waiting for good stuff to be written.
Anyways, the utcOffset reported by the master is kept in data structures
and passed over to slaves.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>