feat(gps): Add universal GPS module support with position estimation

[amanpd7]

Implemented comprehensive GPS support with automatic module detection,
multi-protocol parsing, and home position tracking for navigation features.

Hardware Support:

• Neo-6M (NMEA mode) - tested with firmware 7.03
• Neo-7M (NMEA mode)
• Neo-M8 (UBX NAV-PVT)
• Neo-M9 (UBX NAV-PVT)

Core Features:

• Auto-detect GPS module type from firmware version string
• Dual protocol mode (UBX + NMEA) for maximum compatibility
• NMEA sentence parsing:
  • GGA: position (lat/lon), altitude, satellite count, fix quality
  • RMC: ground speed, heading, UTC date/time
• UBX binary message parsing:
  • NAV-PVT: all-in-one solution for M8/M9 modules
  • NAV-POSLLH + NAV-VELNED: legacy support for M6/M7 modules
  • NAV-SAT: satellite information and signal quality

Position Estimation Features:

• Home position tracking with configurable auto-set behavior
• Haversine formula for accurate distance-to-home calculation
• Bearing calculation for return-to-home navigation
• Support for GPS rescue mode prerequisites (distance/direction)

Implementation Details:

• Configure GPS port for dual protocol (inProtoMask/outProtoMask = 0x03)
• Skip NMEA disable step for M6/M7 modules to preserve data stream
• NMEA coordinate conversion: DDMM.MMMM → degrees × 10⁷
• Unit conversions: knots → mm/s, meters → mm for consistency
• Rate: 1 Hz GPS updates, 5 Hz update check interval
• UART2 configuration: 9600 baud, GPIO16 (RX), GPIO17 (TX)

Tested Configuration:

• ESP32 with Neo-6M GPS module
• Outdoor testing with 7+ satellites
• Position accuracy: <5 meters horizontal
• Full telemetry: lat/lon/alt/speed/heading/time

Related: Phase 1 of GPS rescue mode implementation

[rtlopez]

I've briefly reviewed your changes, and they look quite promising, but I'll continue to study them. However, I'm concerned that using the M6 ​​or M7 for navigation in the future will do more harm than good. The reliability and accuracy of these sensors is very low. Even if I accept these changes, their use will be limited to logging and displaying position in the OSD. For good navigation, you need a sensor capable of providing samples at a frequency of at least 10Hz. This requires disabling NMEA and increasing the port's baud rate. At first glance, your changes seem to do the opposite. Ultimately, that's how I'd like it to work, and considering the current prices of M8 and newer modules, it's hard to justify the need for NMEA support.

[amanpd7]

Thank you for the feedback! You're absolutely right about the limitations of M6/M7 modules for navigation. The 1Hz update rate and 9600 baud are indeed inadequate for reliable flight control.
I added NMEA support as a temporary solution since I only had a Neo-6M available for development. My goal was to start implementing GPS-based navigation modes and failsafe mechanisms immediately rather than waiting for newer hardware.
However, I completely agree that supporting legacy modules adds unnecessary complexity for what would only be suitable for logging/OSD display. I'll revise this PR to:

Remove all NMEA parsing code
Focus exclusively on M8/M9 modules with UBX NAV-PVT
Configure for proper navigation: 115200 baud, 10Hz update rate, UBX-only protocol
Keep the home position tracking and navigation calculations (haversine distance, bearing)

I've ordered a Neo-M8 module and will test the updated implementation properly before resubmitting. The core navigation algorithms (distance/bearing calculations) are already working and tested - they just need to run with proper 10Hz GPS data.
Thanks for maintaining high standards for flight control code. I'll have the updated PR ready soon with M8/M9-only support suitable for actual navigation use.