Fix for Issue #75 - Correct Handling of All_Link Commands

[krkeegan]

What this does:

• Direct Cleanups from Devices to a PLM_Scene are essentially ignored, there really is nothing to process with them.
• An All_Link_Failure report (which occurs when an individual device doesn't respond) now causes MH to push a direct message for that device to the front of the queue. MH will then retry as normal to appropriately set this device.
• MH should wait until the All_Linking process is complete before trying to send another message. (If we try to send a message before the linking is done, we will cause the All_Link process to fail). The All_Link process can take a while (6 seconds for 20 devices in my case). So in order to prevent a lockup waiting for a confirmation that never arrives, MH initially sets the timeout at 3 seconds and then resets the timeout each time an All_Link Direct cleanup ACK is received or if an All_Link_Failure is received.
• MH waits until the ALL_Link Status Report (success or failure) to clear the message.

Of Note:

• All_Link_Failure is only 6 bytes, not 7 as defined in the documentation. I fixed the PLM parsing and Michael's message decoder.
• All_Link_Status always reports success if it was allowed to run completely, even if individual devices fail to respond. Luckily those individual reports are caught by All_Link_Failure. The only way to get an All_Link_Status failure is to send a message from the computer (not a device) to the PLM before the process is complete. If that happens, and it really shouldn't unless the timeout is too short, MH will retry the PLM_Scene again.

I didn't touch Device based All_Link Commands:

• The initial broadcast message is ignored.
• The item is only updated when the direct message is received.
• We could do something with the broadcast. (Is it possible that a broadcast would arrive but not the direct message?)

Fixes Issue #75