There was a bug in ptpd-2.1, fixed in ptpd-2.2. This patch solves
the bug in ppsi.

Actually, no bugs in functionality, but diagnostic log was confusing.

Very similar to commit 04a4e74c.
In the ptpd-2.1.0 implementation, the sync_time was read when
it was read back (and then a follow up was sent), because of
the multicast sending on udp. This is not acceptable if we are in
ethernet mode.

implemented a new function pps_gen_set, which makes use of
PPSG_CR_CNT_SET in CR register for UTC timestamp setting

Timestamp handling was not used while sending (ptpd made use of
multicast come back packets by checking is_from_self, see commit
04a4e74c)

buf_in and buf_out need to be aligned, in order not to have bug in msg_pack
and msg_unpack functions. This issue should be better fixed than what done
with the present patch.

end-to-end mode is currently the default working mode. We do not need
pdelayreq - pdelayresp mechanism.

spec_time function, which gives a monotonic 1-second interval count, is
better to be used than spec_gen_time, since timers must be working even
if timestamp is compromised by a temporary bad regulation. This solution
must be implemented in arch-gnu-linux too, by using RAW_MONOTONIC timestamps.

In the ptpd-2.1.0 implementation, the delay_req_send_time was read when
it was read back, because of the multicast sending on udp. This is not
acceptable if we are in ethernet mode.

This is necessary in order not to make is_from_self be confused when receiving
any frame. Actually, MAC address should be get by the board and not fixed
inside the code.

The WRMODE option in Makefile acts as the -g option (run as slave only):
WRMODE=master -> auto detect, becomes master if no announce is received
WRMODE=slave  -> never go to master mode, listens for announce and becomes slave

See commit 9d37ccb1651edc3ea9dac25ebc3092420d84fdf5 in ptp-proposal

This is a major patch, because header files are renamed, and
the header directory with them. Still, no functional change is there.