Wire up orphaned GPS NMEA service into build and test suite

[Jayakrishnan9539]

Problem

services/gps/src/gps_nmea.c implements NMEA $GPRMC sentence parsing
but was never wired into the build: services/CMakeLists.txt didn't
add_subdirectory the gps folder, there was no CMakeLists.txt for the
module itself, and no public header existed for eos_gps_parse_gprmc.
A leftover tests_backup/test_gps_nmea.py (a Python mock of the same
logic) suggests a real test for this module was planned but never
finished — the module was completely untested and unreachable.

Approach

• Added services/gps/include/eos/gps_nmea.h as the module's public
  API, following the header conventions used by sibling services.
• Updated gps_nmea.c to use that header and gated it behind
  EOS_ENABLE_GPS, matching how every other service module in this
  repo is structured (e.g. services/sensor).
• Added services/gps/CMakeLists.txt to build it as a static library
  and wired it into services/CMakeLists.txt.
• Ported the orphaned Python mock test into a proper C test
  (tests/test_gps.c), registered in tests/CMakeLists.txt, with
  additional coverage for invalid/void fixes and malformed input.
  Math-library linkage is gated with if(UNIX AND NOT APPLE),
  matching the existing pattern used by test_sensor/test_motor_ctrl.

Testing

Verified on two toolchains:

• Linux/GCC: cmake -DEOS_BUILD_TESTS=ON -DEOS_PLATFORM=linux, full
  suite via ctest — 25/25 pass, including the new test_gps.
• Windows/MSVC (VS Build Tools, NMake generator): built and ran
  test_gps directly — all 5 assertions pass. (Note: the full suite
  doesn't build under MSVC due to an unrelated pre-existing GCC-style
  inline-asm usage in kernel/src/task.c — not touched by this PR.)

Limitations

This wires up and tests GPRMC parsing only. The driver-layer GPGGA
parser (drivers/src/gps_nmea.c) has a separate, similar gap and
could be a follow-up.

[srpatcha]

Verified — orphaned code with a ported test is exactly the right trade

services/gps/src/gps_nmea.c existed, parsed $GPRMC, and was reachable from nothing: no add_subdirectory, no module CMakeLists.txt, no public header. Dead source in a repo is worse than absent source — it reads as capability the platform has.

Spotting tests_backup/test_gps_nmea.py and porting it rather than writing fresh assertions is the part I want to call out. Someone had already worked out what the parser should do; recovering that is cheaper than rediscovering it, and the added coverage for void fixes and malformed input is what the mock was missing.

Confirmed the test is not a trivial pass:

[PASS] gps gprmc valid fix
[PASS] gps gprmc void fix
[PASS] gps gprmc rejects non-GPRMC sentence
[PASS] gps gprmc rejects null args
[PASS] gps gprmc rejects short sentence

Four of the five are rejections, which is the right balance for a parser fed off-device input. ctest -N shows test_gps registered as #22, so it runs in the default suite rather than only when someone asks for it.

Gating behind EOS_ENABLE_GPS and following the services/sensor layout is the correct call — matching the sibling modules matters more here than any individual structural preference.

Merge order

This conflicts with #82, which repairs master. The conflict is in tests/CMakeLists.txt and is not semantic: your branch predates test_devicetree and the fuzz subdirectory landing, so master's side is a strict superset. Keep master's block and add your test_gps registration to it.

Resolved that way locally: configure OK, 0 build errors, ctest 29/29, test_gps among them.

Verification

Merged onto origin/master + #82. Not verified against master alone, because master does not currently configure — the duplicate add_test(NAME test_crypto_aes) that #82 removes.

[srpatcha]

Approving. Wiring up orphaned code and giving it a test is exactly the right
shape, and I verified it works rather than taking the diff's word for it.

GitHub reports this DIRTY, but the conflict is not in your change. Your branch
predates test_devicetree and the fuzz-target block being added to
tests/CMakeLists.txt, so the merge sees them as removed. Nothing in the GPS
work is involved.

Verified

Applied onto a base where master's duplicate crypto targets are repaired —
necessary, because on master today CMake fails at configure and no test target
generates at all, so CI here cannot run anything (#92 / #93):

0 build errors
100% tests passed, 0 tests failed out of 29      (28 before, +test_gps)

$ ctest -R gps
100% tests passed, 0 tests failed out of 1

[PASS] gps gprmc void fix
[PASS] gps gprmc rejects non-GPRMC sentence
[PASS] gps gprmc rejects null args
[PASS] gps gprmc rejects short sentence
All GPS NMEA tests passed.

The four negative cases are the valuable part. A parser test that only feeds it
well-formed sentences tells you the happy path works and nothing about what
happens when a real receiver emits a truncated line — which is the case that
actually occurs in the field.

if(UNIX AND NOT APPLE) target_link_libraries(test_gps PRIVATE m) is the correct
guard; Darwin folds libm into libSystem and linking m explicitly is at best
redundant there.

To resolve the conflict

Rebase onto current master and keep both sides — the test_devicetree block
and the add_subdirectory(fuzz) line from master, plus your test_gps block.
There is no semantic disagreement to settle; they are separate additions to the
same file.

One thing to watch when you do: applying your patch with --3way already inserts
the GPS block, so re-adding it by hand produces

add_executable cannot create target "test_gps" because another target with
the same name already exists.

I did exactly that while verifying, which is worth mentioning because it is the
same duplicate-target error that currently stops master configuring — an easy
one to reintroduce during a manual resolution.