Refactoring GPS management into a LocationProvider hierarchy

[alexsporn]

I've been working on cleaning up how GPS is handled across the codebase. Currently, GPS lifecycle management (detection, start/stop, coordinate updates, settings) is buried inside
EnvironmentSensorManager, and several variants have created their own SensorManager subclasses just to handle GPS differently. This has led to a lot of duplicated code: 5 separate SensorManager
subclasses (HWTSensorManager, SolarSensorManager, MASensorManager, NanoG2UltraSensorManager, ThinkNodeM1SensorManager) that all reimplemented the same GPS start/stop/settings logic.

What this PR does

• Moves all shared GPS management into the SensorManager base class, so any variant can add GPS support by calling registerLocationProvider(): no custom subclass needed
• Introduces a LocationProvider base class with a proper hierarchy:
  • MicroNMEALocationProvider: serial NMEA GPS with configurable enable/reset/standby pins and per-chip polarity
  • L76KLocationProvider: Quectel L76K with PCAS command configuration
  • RAK12500LocationProvider: WisBlock I2C GPS (u-blox), extracted from EnvironmentSensorManager
  • T1000eLocationProvider: Airoha AG3335 with PAIR commands and backup mode power management
  • HeltecTrackerLocationProvider: UC6580 with custom pin handling
• Removes the 5 redundant SensorManager subclasses mentioned above, those variants now just use EnvironmentSensorManager directly
• Adds hardware standby support in MicroNMEALocationProvider for chips that support low-power sleep without full power cycling (preserves ephemeris for faster fixes)
• Removes the PERSISTANT_GPS build flag, GPS lifecycle is now always managed through the provider's begin/stop cycle

Impact on variants

For most variants, the change is minimal, just passing &rtc_clock to the MicroNMEALocationProvider constructor (Note that to reduce the size of the PR I did not add this to all boards, there is a separate PR doing this here already) . Variants with custom GPS hardware (T1000-E, Heltec Tracker, Nano G2 Ultra,
RAK4631) have bigger changes since their GPS code moved from inline target.cpp implementations into proper LocationProvider subclasses.

Things I'd like feedback on

• The registerLocationProvider() pattern supports up to 4 candidates that get probed during begin(). Currently only RAK4631 uses multiple providers (serial GPS + RAK12500 I2C). Does this
  approach make sense, or is there a simpler way to handle multi-GPS boards?
• MicroNMEALocationProvider now has a configure() hook that subclasses override to send chip-specific commands after each power-on. This felt cleaner than putting chip config in variant code.
  Thoughts?

The net result is about 300 fewer lines of code across the project, with GPS support that's easier to add to new variants.