Get_first_emtpy_address - ALDB entries that lack an address should be ignored

When a link is added by MH, the record is first put into the aldb hash without an address as a sort of placeholder.  Get_first_empty_address is then called to find an empty location in which to put the record.

Get_first_empty_address then loops through the aldb hash looking for the lowest used address.  In looping, it will come across the record that was just described, which lacks an address.  The subroutine then hexes the address, or lack there of, which for the placeholder results in an address of 0.  The subroutine then improperly interprets this, the 0 result, as the lowest address.

This results in bizarre situations.  In the most benign situation, the subroutine reports that it cannot find an unused address which results in an error requesting a re-scan of the device (this was happening to me a lot).  In the more dangerous situation, the subroutine may report a used address as being empty which results in that address being over written.

This patch prevents an address of 0 from being used as a low address, effectively ignoring the placeholder added above and preventing the issues described.
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.
Increase Send Timeout for Peek Related Messages

The timing of peek related messages is crucial.  In order to prevent receiving messages out of order, we need to increase the send timeout dramatically.
Merge pull request #47 from krkeegan/insteon_hops

Numerous Corrections to Hop Counts
Merge pull request #44 from krkeegan/empty_aldb

Get_first_emtpy_address - ALDB entries that lack an address should be ignored
Skip scanning rest of address if aldb_flag shows address not in use

MH dumps addresses not in use already, but continues to send 7 peek messages after discovering the address is not in use.  There is no need for this in the current code.  This should make scanning faster for those of us who add and delete links from our devices often.
Fix typos in fix for issue #46
Clean up coding mistake.  pending_aldb->address doesn't exist yet
Merge branch 'fix_issue_46' into aldb_delta_v2