APRS parsing logic changes

Today I did two changes which were recently requested by aprs.fi users.

The first one was actually done last weekend, but it needed some more testing and cleaning up, so I only deployed it on the production server today. The MIC-E parser now accepts some forms of corrupted packets. There are a number of broken igates and digipeaters out there, which corrupt MIC-E packets which often contain non-printable, non-ASCII characters in the 0x1C-0x1F range. At least aprsd has this bug (there is a patch in it's bug tracking system which fixes it) - it replaces the characters with spaces (0x20), and it seems that some igates or APRS-IS servers then replace the spaces with a single space, so that the MIC-E data is really broken.

I've added a kludge which manages to parse the location from some of these corrupted packets. It's ugly, but it usually works. Replacing corrupted or missing data with something I've guessed is not a good idea, but this will have to do for a while.

The second one was pointed out only last night by Chris, K6DBG. The speed of a target is now calculated from the positions of the current packet and the previously transmitted packet, instead of the previously accepted and stored packet. This is significant, because packets indicating that the target is moving faster than 500 km/h are discarded. These are usually caused by corrupted packets, or bad GPS data. Some APRS trackers transmit their position even if the GPS clearly indicates that it has no valid fix. Sometimes the GPS suddenly gives out a single invalid point which is hundreds or thousands of kilometers away.

If the invalid position was the first one transmitted by the station, it was accepted and stored to the database, and it could take days (to move to the true position at 500 km/h) before a new correct position packet was accepted. Now, the second correct position packet is already accepted and stored.