Allow for Hop Count of 0 and Set Initial Hop Count to 0

The lowest hop count permitted by Insteon is 0 not 1.  A hop count of 0 means that the PLM will send the message, but no other devices are to repeat the message.  Generally devices near the PLM will not require any hopping.

-Fixed code to allow for setting a device's hop count to 0.
-Added message flags for hop counts of 0
-Set the initial hop count for new devices to 0

It is important to be judicious with increasing hop counts.  As hop counts increase, more messages are sent around the network which can lead to unintended interfence.  In addition, increasing the hop count increases response times.  This is because the responding device will not respond until all possible repeats of the message have occurred.  Even if a device hears the message on the first broadcast, it will wait for all hops to occur before responding to avoid collisions.
Fix calculation of send_timeout based on hop_counts

-Updated to allow for a hop_count of 0.  The comments in the file noted that a hop count of zero should exist, but never made allowances for it.

-Fixed the calculation used to determine the hop count.  Looks like a logical error, send_attempts was being added to default_hop_count and then decreased by one.  Not sure the logic here.  Default_hop_count is equal to send_attempts up to 3 attempts, so unless the device lacks a default_hop_count, which I believe is only the PLM, there is no need to look to send attempts.  Moreover, adding send_attempts and hop_count was resulting in an anomolous situation in which the timeout could be double what it should be.

-Shifted hop_count timeout allocations by one.  This matches what is in the comment section, but for some reason was not implemented.
If a message is recieved with hops left, delay sending the next message

If a message arrives with hops left, then it may arrive again on the next hop.  In order to avoid collisions and to avoid confusing the logic on MH delay sending the next message just slightly to allow for any remaining hops to occur.
Add brief pause between receiving and sending messages

-Decreased timeout for messages received with hops_left.

-Added a slight 50 millisecond pause between receiving messages and sending the next message.  This allows a brief moment for duplicate messages to arrive.  I receive a number of duplicate messages with the same hop count.  I believe these are caused by bridging between the powerline and rf signals, apparently this doesn't decrease the hop count.  This slight pause of 50 milliseconds allows the second message to arrive, which as long as the next message has not been sent yet is gracefully ignored.
Merge branch 'insteon_hops' into running