Better ACK handling

[nseidle]

This PR re-writes how we look for responses from sendCommand(). Instead of assume an ACK is valid we explicitly look for the correct ACK depending on the type of packet being sent. From the UBX datasheet:

When messages from the class CFG are sent to the receiver, the receiver will send an "acknowledge"(UBX - ACK - ACK) or a "not acknowledge"(UBX-ACK-NAK) message back to the sender, depending on whether or not the message was processed correctly. Some messages from other classes also use the same acknowledgement mechanism.

For packets intended to re-configure the Ublox module, we look for an ACK but this is split into two cases:

1. We may be querying a setting in which case we expect the packetCfg to be filled with the current setting data, and then the UBX should send an ACK. These two cases must be achieved for waitForACKResponse to return success.
2. We may be sending new data into a setting in which case we expect an ACK but no data in packetCfg.

For packets intended to merely get data from the Ublox module (for example a PVT packet), we look for packetCfg to be filled but there will be no ACK. We use waitForNoACKResponse. For NoAck responses, we still verify that the CLS/ID of the incoming packet (think PVT) match what we asked for.

This PR generally improves the stability of the library. There are still plenty of ways to break it but it's working much better.

There were a few small changes:

• Many more debug statements to help follow the flow.
• Add flushPVT() to allow the marking of all PVT data as stale. Previously, if there was a CRC error PVT readings would get out of line. This method allows us to re-align the data each time we're done reading (for example after we've read lat, long, date, etc and are waiting for a 1000ms to expire).
• Sensitive functions (sendCommand, sendI2cCommand, waitForACKResponse waitForNoACKResponse) now return a status rather than a bool. I think we can expand this overtime to other functions.

Known issues:

• process() will process the entire available buffer of data. This means it is possible for multiple packets (cfg or ack) to be contained within a response from the Ublox module (I saw a 1500 byte read earlier today), of which this library only 'sees' the latest one. The longer the user spends between polling, the worse this can become. We would need to change the core pretty significantly to eliminate this potential but I think it's workable right now for the vast majority of applications.
• The library has grown in size and complexity. We may need to re-think how debug statements are printed. Perhaps with #ifdef guards. Not great for the end user but I don't know of a better way to lighten the library.
• There is still I2C corruption using the Artemis platform. I'm still confused as to why the Ublox modules don't respect I2C setup times.
• The GeoFence example is still acting weird. It's a nice example of a whole bunch of configuration and readings going on so I have still included it but I know the various functions (addGeofence, clearGeofences, etc) work on their own.

[PaulZC]

Ooh, yes. I see what you mean. GeoFence is rather broken at present... I'll start digging!
(I will be mostly AFK from the 29th until the 5th - but I'll do what I can!)
All the best,
Paul

[PaulZC]

I've added some useful stuff in #65. Please don't merge as-is, but it contains clues on where to head next...
All the best,
Paul