Add --server option to start the Remote API server

[martin-gawlita]

Starting Open Sound Meter from a login/startup shortcut currently leaves the Remote API server off until someone enables it in the GUI. This adds --server so desktop setups that depend on remote measurements can explicitly enable it on each launch.

The option calls the existing remote::Server::setActive(true) after the source list has been assigned and the QML root has loaded successfully. The GUI remains available, including the Server switch. Launches without the option keep the existing behavior, and remote generator control remains separately opt-in.

The change also adds Qt's standard --help and --version options and documents Windows, macOS and Linux invocations. Application arguments are now processed by QCommandLineParser, so unknown options produce a command-line error.

Submitted as a draft for discussion in light of the repository's CONTRIBUTING policy. Would this small, opt-in startup option fit the project's direction?

Validation (2026-09-11, commit 0c6dc19):

• Built the full application in release mode with Qt 5.15.2, C++17 and the OpenGL backend, targeting macOS x86_64. Ran it on Apple Silicon via Rosetta (macOS 26.6.2).
• Used Apple Clang 21 and macOS SDK 15.4; the newest local SDK no longer contains AGL required by Qt 5.15. SDK selection and the libc++ header search path were adjusted locally, with no additional application-source changes.
• --help lists --server and exits 0; --version exits 0; an unknown flag exits 1.
• Normal startup and a subsequent restart without arguments both leave TCP 49007 closed and emit no UDP server announcements.
• --server opens TCP 49007, advertises the measurement source through UDP discovery, emits live level messages, and answers a TCP requestChanged request with sourceSettings.
• The advertised generator is disabled, as expected.
• In the actual GUI, Server is initially checked; switching it off closes the TCP port and switching it on reopens the port. Normal GUI quit also succeeds.
• Tests used a temporary profile; the original user profile was restored and verified byte-for-byte.
• Repeated the complete CLI/network test sequence against the self-contained app bundle produced by macdeployqt; all checks passed. Ad-hoc code-signature verification also passed.
• git diff --check passed.

Windows x64 validation (same application source; build automation only in the fork):

• Built a native AMD64 release with MSVC and Qt 5.15.2 on windows-2022, and bundled Qt plus the MSVC runtime using windeployqt and app-local runtime DLLs. Build run.
• Verified the packaged EXE and DLLs are AMD64. The initial CI smoke test lacked Qt's offscreen platform plugin; that test setup was corrected and the existing executable was retested without recompiling.
• The corrected package test passes all three cases: normal startup leaves TCP 49007 closed, --server opens it and returns a valid OSM protocol response to a TCP request, and restarting without arguments closes it again. Passing package/API test run.
• Windows smoke tests use Qt's offscreen platform and software rendering on the hosted runner. Real Windows audio hardware and visual desktop interaction were not tested.

This is a desktop startup option, not a headless mode or a Windows service implementation.