Signal K position support

[bergie]

This PR enables getting position from a Signal K instance. If enabled, Signal K will be auto discovered based using mDNS, but you can also configure the instance to use.

Fixes #356

(sorry, first PR was accidentally against master)

[martinhpedersen]

Thanks for the PR!

Signal K support would be useful, but I think we need to introduce an abstraction for position sources before adding another implementation.

Pat currently has two position sources:

• The HTML5 Geolocation API, currently available only to the frontend.
• GPSd, used independently by the API, position command, forms manager, and locator updater.

This PR adds Signal K selection, connection, fallback, conversion, configuration, and error handling separately to several of those consumers. For example, the API, CLI position command, forms manager, and locator updater each need to know how to connect to Signal K and how it relates to GPSd. This duplicates source-selection policy and makes each consumer responsible for implementation-specific behavior.

It also expands the top-level configuration with another set of source-specific options such as allow_forms, use_server_time, and update_locator. These are mostly policies governing how Pat may use position data rather than properties unique to Signal K. Continuing this pattern for additional sources would increase both the configuration and maintenance burden.

I think we should first introduce a common position-source abstraction. We could take inspiration from the engine concept used by AX.25 and discussed for PACTOR in #529, while accounting for the possibility that users may want an ordered set of sources with priority or fallback rather than exactly one engine.

The abstraction should be responsible for:

• Initializing and managing configured position sources.
• Providing a source-neutral position type to the application.
• Selecting between sources according to configured priority and availability.
• Validating freshness and accuracy before returning a position.
• Supporting both backend sources and positions supplied by the frontend.
• Applying common policies for forms access, HTTP exposure, timestamps, and locator updates.
• Keeping source-specific discovery, connection handling, and conversion out of the API, CLI, forms manager, and App.

Consumers should request the current position from one application-level service without knowing whether it came from GPSd, Signal K, the browser, or another future source. Signal K-specific concerns, including mDNS discovery and subscription handling, should remain behind its source implementation.

I have been considering this abstraction for a while without settling on the exact design, but this PR demonstrates why we need to establish the boundary now. Otherwise, adding each new source requires modifying every position consumer and duplicating fallback and policy logic.

I suggest addressing the shared position-source abstraction first, then implementing Signal K behind it.