help: default the contextual layer off, and carry the help into the chooser

The contextual help was on by default, so a first run met a window with a "?"
beside every surface it had not asked to have explained; `contextual_help` now
defaults to false and the layer is asked for from the Help menu, from the
chooser's new help menu, or with Ctrl+H.

The source chooser runs before `App` exists, which makes it the window a user
who does not know how to start is looking at, so it now carries the same three
help affordances the window's Help view does: Documentation (the manual is
another process and needs nothing of the app), Enable contextual help (a row
whose check *is* the setting, written to the file the app reads a moment
later), and Guided tour. The tour is drawn on the app's own window, so the
chooser can only record the wish: it sets `Config::tour_pending` -- the value
`main()` owns and hands to both `choose_source()` and `run_ui()` -- and
`on_activate()` starts it once the window is up and laid out, through its own
callback so the readings can tell a request from the first-run auto-start.
The rows are the window's own `menu_button()`/`menu_toggle()`; `install_css()`
therefore runs from `choose_source()` (it is idempotent now) so the popover
gets the `.udpscope-menu` rules before it is shown.

Opening the manual could also fail with a message that blamed the handler
whatever was missing. `help_installed_path()` now resolves `help:<id>` the way
the specification does and the failure alert says which of the two it is: with
the set installed it names the viewer, without it it names the identifier, the
expected installed path and the install command. `show_help()` gained an
optional reporter, which `UDPSCOPE_PROBE_HELP_MS` uses for a new reading --
`[help] launch attempted= done= ok= error='' installed=` -- since a successful
launch leaves no window of ours to observe.

Tested: clean --clean-first build, three warnings as documented; test-ui 13/13
and test-help pass; no Gtk-CRITICAL in the help, helpui and chooser runs.

src/ui.cpp

@@ -5142,8 +5142,15 @@ void on_activate(GtkApplication* application, gpointer user) {
   // A first run is the run whose settings file does not say the tour has been offered -- see
   // `tour_autostart()`. Delayed rather than fired on the first tick: the window has to be up and
   // laid out for the tour to have anything to point at, and a tour that opened on the frame the
-  // window appeared would be a spotlight on a widget with no allocation yet.
-  if (!app->settings.tour_seen) g_timeout_add(1500, tour_autostart, app);
+  // window appeared would be a spotlight on a widget with no allocation yet. The source chooser's
+  // own "Guided tour" entry arrives as `Config::tour_pending` (the request has to outlive the dialog
+  // that made it -- the tour is drawn on *this* window) and gets the same delay for the same reason,
+  // through its own callback so the two are told apart in the readings.
+  if (app->model->config().tour_pending) {
+    g_timeout_add(1500, tour_start_requested, app);
+  } else if (!app->settings.tour_seen) {
+    g_timeout_add(1500, tour_autostart, app);
+  }
 
   // Bubble phase on purpose: a focused GtkEditable or GtkButton wins its own keys, so typing
   // 'm' into the window entry does not toggle the measurements pane and Space does not