Add RAK12501 L76K GPS support for RAK3401

[mathisono]

Summary

Adds RAK12501 / Quectel L76K UART GPS initialization for the RAK3401 1W target.

This keeps the change scoped to the RAK3401 variant by:

• wrapping the existing MicroNMEALocationProvider in variants/rak3401/target.cpp
• sending the L76K PCAS init sequence after GPS reset
• updating the RAK3401 GPS pin macros so MeshCore's existing Serial1.setPins(PIN_GPS_TX, PIN_GPS_RX) call maps to MCU RX/TX correctly
• avoiding use of WB_IO2 / PIN_3V3_EN as a GPS enable pin, because that rail is shared with the RAK13302 1W PA support rail

GPS init behavior

The RAK12501/L76K wrapper sends:

$PCAS04,7
$PCAS03,1,0,0,0,1,0,0,0,0,0,,,0,0
$PCAS11,3

[Avamander]

You might also want to enable Glonass and if your board has known time, inject that too for a quicker fix. (In theory you could also provide approximate location as well or entire almanac, but that's harder to ship.)

[ripplebiz]

Looks good, but need you to change the base branch to 'dev'

[liamcottle]

Please make sure to rebase it on the dev branch too, and not just change to dev branch in GitHub UI ;) Otherwise it will pull in all the commits from your main base branch.

[disq]

Heads up that this overlaps with #2640, which already includes the same PIN_GPS_RX/PIN_GPS_TX swap for the RAK3401 plus the shared-rail power handling (including RAK12501 support).
One thing to note: #2640 routes the RAK3401 through the RAK_WISBLOCK_GPS init path, where reset() is never called, so the PCAS init here would become dead code if both merge. Might be cleanest to land #2640 first and rebase the L76K PCAS config on top, hooked into that path. The config itself would be a nice addition. Happy to help coordinate.

[mathisono]

@liamcottle I rebased my RAK3401/RAK12501 GPS branch onto dev and narrowed it to L76K-specific config work: enabling GPS+BeiDou+GLONASS, reducing NMEA output to RMC+GGA for companion-radio responsiveness, set vehicle mode, and optionally injecting known RTC time with PMTK740 for faster TTFF if its past 2020-01-01.

Thanks for the heads up that this overlaps with #2640 on the RAK3401 pin swap/shared-rail handling, I will yield to let #2640 merge first. @disq after that lands, I’ll rebase my branch on top of the updated dev and move/adjust the L76K PCAS/PMTK config into the RAK_WISBLOCK_GPS serial path introduced there, so the PR becomes a clean follow-up rather than duplicating #2640. I will rebuild and test on my HW and submit a new PR. 73

[IoTThinks]

• avoiding use of WB_IO2 / PIN_3V3_EN as a GPS enable pin, because that rail is shared with the RAK13302 1W PA support rail

This is a good hint.
Looking forward to your new PR (based on dev).
Both 12500 and 12501 GPS modules are broken on RAK3401.