Add functionality for sending and maintaining neighbor status

struct hrdw_addr needs fields describing the local and remote status
(failure status and clock time) of a neighbor. The first 31 bits of
the remote status are the remote node's clock, and the 32nd bit of
the remote status is the failure status (0 for failed, 1 for alive).
The local status is simply the local clock, which uses all 32 bits.

All clock times are the lower 32 bits of the wall time, measured in
seconds.

Since the 32 bits of the status are split up, functions
set_remote_status() and set_remote_clock() are added to ensure users
safely update these fields using bit masks.

Because neighbors now have a status associated with them, NWP
needs methods of disseminating that information. To do this,
the routines for announcing and sending neighbor lists must
be amended to include status information.

Status information can be taken from announcement and neighbor list
packets in read_announcement() and process_neigh_list(), and can be
passed to functions that create and insert neighbors, such as
new_ha(), add_ha(), and insert_neigh().

main_newroute() in net/xia/ppal_hid/main.c must also be altered
to match the change in function signature for insert_neigh(),
and the function prototype must be changed in
include/net/xia_hid.h.
Introduce new NWP packet types and alter old ones

There are five new types of monitoring packets which are used
for detecting failure or disconnection between neighbors in a
LAN.

struct monitoring_hdr is the basic header for a monitoring
packet. Two or three hardware addresses are also placed in
the monitoring packet, depending on which part of the
monitoring process is happening. monitoring_hdr_len() can be
used for the convenience of other function to compute the
minimum monitoring packet length, for example.

Because each neighbor now has a status, it is necessary to
convey those statuses not just in the monitoring packets but
in announcement and neighbor list packets as well, so those
packet headers needed to be altered.

Because monitoring packets have a reserved field, we need to
move the packet-dropping checks for the number of HIDs and
the hardware address length to announcement- and neighbor
list-processing code.
Allocate, initialize, and free new monitoring fields

Every struct hid_dev now has two timers: one to periodically
begin a monitoring interval, and one to periodically clean the
neighbor list by deleting failed interfaces and neighbors. We
also need to allocate memory for a temporary target for each
monitoring interval.

There are also bools for whether monitoring is currently
occuring, for determining whether contact has been made with
any neighbor during the current monitoring interval (to
diagnose network partitions), and for whether the neighbor has
yet been remonitored if failure is suspected.

hdev_init() needs to initialize the timers, the target, and
the bools, and hid_dev_finish_destroy() needs to do the
opposite by deleting and freeing memory for the monitoring
data structures.
Add functionality for cleaning neighbor list

NWP monitoring has the power to detect and declare interfaces and
neighboring HIDs as failed. clean_neigh_list() is periodically
called by a timer in each hdev to clean the neighbor list of any
failed nodes by deleting them.
Add efficient monitoring functionality

Upon arrival of a neighbor list, the monitoring algorithm may
begin in process_neigh_list(). monitor() initiates a monitoring
interval, using pick_random_neigh() to select a random target
to monitor.

To accomplish this, the monitoring algorithm first pings the
selected target, which may result in a timer expiration and
callback of end_ping_failure(). In that case, investigative
neighbors may be used to verify that the given target has
failed. If, at the end of the investigative time period, no
response from the target has been received, a timer expiry
callbacks into end_interval_failure, which may declare a node
as failed.

The forward declaration of end_interval_failure() is necessary
because of the cyclic nature between monitor(),
end_ping_failure(), and end_interval_failure().

In order to send monitoring packets, send_monitoring() is
implemented. Note that const u8 *inv should not be used
for Ping and Ack packets, and in those cases should be set to
NULL.
Enable receipt and processing of monitoring packets

nwp_rcv() may now accept monitoring packets and distribute
them to process_monitoring(), which updates clocks, changes
timers, and dispatches packets as necessary depending on the
type of packet that has been received.

Since monitoring packets may now be received, it is possible
for monitoring to be successful (the target responds). Hence,
end_interval_success() is added.
Fix spelling of announcement

All uses of NWP_TYPE_ANNOUNCEMENT have been fixed for spelling.