Fix epoch in send message

[hickey]

This fixes the problem of creating messages with bad or bogus timestamps when epoch is not specified in the send_message API call.

Closes #15

[gerner]

I'm not super familiar with this bug, but LGTM

[n2mh]

Would it also make sense to also do a simple check to see if an incoming timestamp is in the future? If so, discard it and use the present time? Or, some other action?

[hickey]

I have been thinking about putting guardrails around the epoch value, but I am not certain what the appropriate amount of variance is good. The code from KN6PLV was allowing up to 30 days in the future (which I think is still there) but that seems way too excessive to me. Nodes tend to be lousy time keepers and so there certainly should be a +/- number of secs or mins that a message would be allowed to have. If anyone has any suggestions, I am willing to give it a try with suggested time deltas. I will actually put values in the config file so that it can be tuned rather than constantly releasing new code trying to find good values.