EDDN: Don't blindly replay old messages 'as' the current application version

[Athanasius]

With reference to #1403 it is entirely possible for someone to be playing with "Delay sending until docked", such that they get EDDN messages recorded under one EDMC version and some time later they actually get sent (first attempt) under a later version.

The current plugins/eddn.py:EDDN.send() code blindly uses the current application version in the EDDN message's softwareVersion field.

This can thus give the false impression that this 'current' version has a bug that it doesn't, if an older version built a bad message that has been sat in the replaylog.

So:

• Change the code that puts messages in the replaylog so that it records the current application name and version.
• When EDDN.send() finally sees the message, compare that per-message sofwareName and softwareVersion, and if it's the same, continue as normal.
• But if they differ at all then use the message ones and append (sent with <name> <version>) with respect to what's actually doing the sending. Yes, this might look weird in the EDDN stats, tough. That's only cosmetic, we need to be clear on what happened. We could just append (replaying from older) to limit the set of new spammier version strings, but I'm not sure it's worth trying to avoid the spam.

[Athanasius]

Especially in light of nascent plans to have EDDN messages require a header->gameversion field which will have to be the gameversion of the data source, not at time of sending to EDDN, this is now more urgent.

And I think at this stage we should just make the replaylog record the entire message as it will be on the wire.

And if a message is being replaylog-sent then perhaps append (replay) to header->softwareName to make it clear.

Of course we'll also need to cope with the cases where a user has replaylog entries from before the change.

[Athanasius]

I've started working on this now, it's in https://github.com/EDCD/EDMarketConnector/tree/fix/1431/eddn-replay-enhancements