Use satpulse for the PTP / timing backend

Since the Time Pi is targeted at some specific hardware (though many parts can be genericised), it might be useful to break out the trickier bits of the timing configuration (PTP, NTP, Chrony, etc.) to an application that already does all the things I'm working on there, [Satpulse](https://satpulse.net).

Satpulse includes more features too, like there'll be a web GUI for GPS satellite monitoring.

It's always nicer to work upstream than to just build a separate but (somewhat) equal product that solves all the same problems.

I do wonder one thing about the architecture (haven't read too deeply in the code)—it looks like maybe `chrony` is used for the GPS PPS to NIC time sync? Is that as stable/precise as using `ts2phc`? (Or did I just miss ts2phc being used in satpulse?).

I guess I can ping @jclark and ask directly, haha!

Because `ts2phc` is certainly causing me the most grief so far:

- I had to install a newer version of Linux PTP to get it working correctly with NMEA GPS timestamps
- I still have trouble getting NMEA timestamps to get recognized properly
- Since the Pi's built-in Ethernet (on the Pi 5 at least) doesn't include a PPS input pin anywhere, I _have_ to use a different NIC—in my case an i226—and that introduces it's own little quirks when syncing time from GPS' PPS (notably, with the rising edge detection, which requires a patched driver).

Related: #1.

No files or tests are named. Start by tracing the existing PTP, NTP, and Chrony configuration, then compare it with Satpulse's architecture and the reported ts2phc and GPS PPS constraints. Done would require a settled integration scope and an agreed approach for timing synchronization.

Written by the indexing model from the issue text.