measure: the split's own means are back as above/below/between

`top`, `bottom` and `amplitude` became the *flat levels* in e83ad86 -- the level the
signal dwells at, read from the density of the window's buckets -- and that change kept
the split's own two means as its internal fallback for a window the pyramid cannot
summarize. Those means are now three types of their own, so the two different questions
about one split can be asked side by side: `above %` and `below %` are the plain mean of
the samples on one side of a share -- the reading the old `top`/`bottom` gave -- and
`between % %` is the mean of the band between two shares, which no single split can
answer, because a band's two edges are two thresholds.

Nothing about the arithmetic is new, and nothing is a new pass. `Above`/`Below` are the
`sum[]`/`count[]` split `measure_accumulate()` already folds -- the very figures
`Top`/`Bottom` fall back to -- and `Between` is the **difference of two levels' upper
sides**, both of which come out of one pass two over one window. It rides the bucket
fast path unchanged: a bucket wholly inside the band is strictly above the lower level
and strictly below the upper one, so both accumulators fold it whole, and only the
buckets that straddle either edge are opened. `measure_level_pcts()` is the one place the
shares are read, and it clamps both and puts `between`'s pair **in order**, so "between
80 % and 20 %" is the band between 20 % and 80 % -- normalized rather than refused,
because the shares name two edges rather than a direction. Nothing to measure reads `--`,
as for every other type: a share at 100 % has no sample above it, and a band can hold
none at all.

Measured, `[bandavg-probe]`, fast mock at a 2 s window (`--rate 1300000 --batch 1000
--freq 1`):

  sine   `above 50` 0.636620 (2/pi), `below 50` -0.636620, `between 50 75` 0.255873
  square `above 50` 0.986496 (30 harmonics) / 1.000000 (--square-harmonics 0),
         `between 50 75` 0.302744 / --
  ramp   `between 50 75` 0.250000 and `above 50` 0.500000, `above 100` --

The first three are the figures the old `top`/`bottom` documented; the ramp's are what a
uniform density predicts (a band's mean is its own centre); the ideal square's empty band
is the nothing-to-measure rule. The pane offers the types and edits their percentages
through the dialog's second share -- which only `between` shows -- and a measurement's
pair survives add/edit/delete and the session file (`threshold2`), where a file written
before it existed loads at the default.

No raw pass: with the measurements probe adding one of every type at a 2 s window, `raw`
went from 113966 of 240719031 covered (0.0%) to 134978 of 255372033 (0.1%), 0.8 -> 1.1
ns a covered sample.

Docs: the band-average invariant (and the two assertions the flat-level change moved),
the probe readings for the new probe, the verification recipe, the manual's measurements
page and the README.

src/ui_app.hpp

@@ -584,6 +584,10 @@ struct App {
   /// it is a window of its own, so the main window's widget tree does not reach its buttons.
   GtkWidget* measure_dialog = nullptr;
   int dbg_measure_step = 0;
+  /// The band-average probe's own step counter. Its own rather than the measurement pane's: the two
+  /// probes add measurements, so they must not be scheduled in one run (see verification.md), and a
+  /// shared counter would make that a silent mis-step rather than a documented prohibition.
+  int dbg_bandavg_step = 0;
   int cursors_pane_mode = -1;
   int cursors_pane_rows = -1;
   unsigned cursors_pane_generation = ~0u;
@@ -1174,6 +1178,9 @@ struct MeasureDialog {
   GtkWidget* signal_drop = nullptr;
   GtkWidget* type_drop = nullptr;
   GtkWidget* threshold = nullptr;
+  /// `Between`'s *other* edge: the same unit as `threshold`, shown only for the one type that reads
+  /// two shares (see `measure_uses_band()`).
+  GtkWidget* band = nullptr;
   GtkWidget* above = nullptr;
   GtkWidget* show = nullptr;
   GtkWidget* window = nullptr;
@@ -1182,6 +1189,8 @@ struct MeasureDialog {
   /// and the difference has to be in words, not just in visibility.
   GtkWidget* threshold_row = nullptr;
   GtkWidget* threshold_label = nullptr;
+  GtkWidget* band_row = nullptr;
+  GtkWidget* band_label = nullptr;
   GtkWidget* side_row = nullptr;
   GtkWidget* side_label = nullptr;
   /// The two noise-rejection rows. `noise` is a percentage of the window's peak-to-peak, `hf` a corner in
@@ -1502,6 +1511,10 @@ void on_layout_drag_update(GtkGestureDrag* gesture, double offset_x, double offs
 void on_layout_drag_end(GtkGestureDrag* gesture, double offset_x, double offset_y, gpointer user);
 void on_trigger_toggled(GtkToggleButton* button, gpointer user);
 plot::u32 measure_color(std::size_t index);
+/// One line naming what a measurement's type is measuring, with the shares it reads them at: the
+/// pane's row tooltip. The row's own label is the type alone (as for every type), so this is where
+/// a user sees the share an `above`/`below`/`between` row is averaging over.
+std::string measure_row_summary(const Measure& m);
 bool visible_samples(App& app, std::size_t channel, std::vector<double>& time, std::vector<double>& value);
 int measure_channel(App& app, const std::string& signal);
 int measure_row(App& app, const std::string& signal);
@@ -1731,6 +1744,10 @@ void measure_dialog_click(App& a, const char* label);
 void measure_dialog_report(App& a, const char* what);
 void measures_probe_next(App& a, int step, guint delay_ms);
 gboolean measures_probe_step(gpointer user);
+void bandavg_probe_next(App& a, int step, guint delay_ms);
+void bandavg_report(App& a, const char* what);
+int bandavg_index(App& a, MeasureType type, const char* signal);
+gboolean bandavg_probe_step(gpointer user);
 gboolean zoomkeys_probe(gpointer user);
 void menus_probe_next(App& a, int step, guint delay_ms);
 void menu_row_labels(GtkWidget* box, GtkWidget** label, GtkWidget** accel);