Multiplayer bombable sometimes erroneously reports 100% damage after damage reset

[bhugh]

In Bombable, the remote MP reports damage added and also total damage (as far as it knows, based on previous damage reported by the base a/c plus damage added by the remote a/c). This is important because if mp messages go missing, the base a/c will miss adding the damage from the missing messages. Since the remote a/c reports cumulative damage, the base a/c can increase it's total damage to the remote a/c's reported cumulative damage level and all is well.

When resetting damage, the host a/c sends out and mp message telling the remote a/c to reset cumulative damage to zero.

When playing with 3 players over mp recently we had a situation where one remote a/c kept reporting 100% damage back to the host a/c, even after the host a/c had reset damage to 0%.

This could have a few different causes:

1. remote a/c never received the host a/c damage reset
2. remote a/c received the message but some bug prevented it taking effect
3. Possibly the bug was in some previous bombable version
4. malicious code was added to bombable to periodically send 100% damage messages to the host a/c

I don't believe #4 was the cause here, but it is always a possibility and we should try to prevent that from happening where possible. Sending the '100% damage to your enemy' bombable mp message is actually quite easy and some players might see this as the ultimate cheat code.

Here is a solution that should help with all 3 possible causes:

1. Every time host a/c resets damage it increments a counter, let's call it reset_counter.
2. It broadcasts the new reset_counter to all remote a/c via an mp message along with the reset mp message
3. Whenever remote a/c broadcast damage & cumulative damage back they include the most recent reset_counter value
   1. The host a/c ignores the cumulative damage portion of any remote damage messages unless they include the current reset_counter value. And if it receives an old reset_counter value it can re-send the 'damage reset' mp message to that remote a/c.
   2. Thus, if the reset damage message didn't make it to the remote a/c successfully, the host a/c will know to ignore cumulative damage totals from that remote a/c and will also know to re-send the 'reset damage message'.
   3. A variation on this would be to send a random number as reset_counter rather than incrementing the value in predictable fashion. This wouldn't really be any more overhead and might help defend against some sorts of malicious mp damage messages.