Implement gpsd client support (for NEO-6M modules)

[rpj]

Will require a re-thinking of sensor runlooping (and therefore is related to #3), as ideally any NMEA stream-producing sensor should act in a push-only manner rather than the current sensor-src-tick-based-pull mechanism (confusingly named _runloop, hence #3).

Redis 5 streams would come in really handy here, but an implementation based on lists and using BLPOP to block consumers until a new datum is available could work well too.

[rpj]

Should track state changes of devices through time (specifically for NEO-6M, stuff like resets and antenna statuses), seem to be found in GPTXT sentences

[rpj]

Would be really awesome to make use of any device that includes an on-board battery as an RTC of sorts for the RPi! I know it's doable...

Update: Most definitely doable: http://www.catb.org/gpsd/gpsd-time-service-howto.html

[rpj]

This really must be implemented as a gpsd client rather than by trying to parse NMEA sentences directly. In this way, we'll be able to implicit take advantage of things like gpsd's ability to produce "cooked" TPV data (and everything as JSON no less!), as well as obviously having a solid, maintained abstraction layer between us and NMEA/etc.