feat: a gallery that shows what the control can do, and four smaller gaps

Running Codejock''s property grid sample beside ours made the difference
obvious, and most of it was not the control. Their sample shows about thirty
kinds of item; ours showed eight, which reads as "this library supports less"
when in fact almost all of theirs are a DataTemplate over the row and always
were. So the gallery now shows them: a tick box with its own caption, a group
of radios, a slider with a spin box, a masked field, an address field, an
upper-cased field, a hyperlink, and a button inside an editor - none of which
needed anything added to the library.

Four things did. A colour now shows its channels beside the swatch, because
the swatch says roughly which colour it is and somebody matching two of them
needs exactly. A description can carry a glyph, and can name brushes for its
own text, its value and its row. And a row can take the whole width with no
name beside it, for a property whose editor is the point.

The per-row brushes are named rather than handed over as objects, so a
description stays a plain object - and setting them taught me something worth
recording next to the code: a brush read from Application.Resources is
whichever theme was current at the time, not the theme of the element it is
about to paint. Writing one back unconditionally painted dark-theme text on a
light window. Now nothing is written unless a description asked, and the value
underneath stays the {ThemeResource} from the template.

The diagnostics moved out to PropertyGridProbe, a separate repository that is
not published, the same way DockingProbe sits beside DockingPanels. It is
scaffolding rather than a sample and nobody cloning this wants it. The
screenshot mode stays: it produces the README image.

Author: joseangelmt

CONTRIBUTING.md

@@ -50,19 +50,26 @@ Control templates, splitter dragging, focus and keyboard behaviour, and the visu
 are validated by running the gallery and trying them. Please say in the pull request what you tried
 by hand.
 
-Two things the gallery can answer without a person watching:
+The gallery can take its own picture, which is how the image in the README is produced and a quick
+way to see that a layout change did not collapse something:
 
 ```
 dotnet run --project samples/PropertyGridGallery -- --screenshot gallery.png light
-dotnet run --project samples/PropertyGridGallery -- --diagnose report.txt
 ```
 
-The first opens the gallery, lets it settle, saves a picture and exits — how the image in the README
-is produced, and a quick way to see that a layout change did not collapse something. The second puts
-four hundred rows through the repeater, scrolls them, and reports what actually happened: how many
-elements were realized, how often they were recycled, and whether the content presenter kept the
-editor it had already built. Those are the questions the design rests on and the ones no unit test
-can reach; if you change how rows are realized, run it and put the numbers in the pull request.
+For the questions a picture cannot answer — does the repeater really virtualize, does it recycle
+rather than rebuild, how tall is a row, and above all *does anything write to the model while nobody
+is typing* — there is a separate throwaway application, **PropertyGridProbe**. It is not in this
+repository on purpose: it is scaffolding, not a sample, and nobody cloning the library wants it. It
+references this one by source, so clone it next door and run:
+
+```
+dotnet run --project ../PropertyGridProbe -- --diagnose report.txt
+```
+
+If you change how rows are realized, run it and put the numbers in the pull request. And when you add
+a measurement there to catch a specific bug, take the fix out and check that the probe reports it —
+a harness that always says zero is not evidence of anything.
 
 Two rules keep the tests possible, and both are easy to break by accident:
 

assets/gallery-dark.png

@@ -5,7 +5,6 @@ namespace PropertyGridGallery;
 public partial class App : Application
 {
     private Window? window;
-    private Diagnostics? diagnostics;
     private ScreenshotRun? screenshot;
 
     public App()
@@ -19,15 +18,7 @@ protected override void OnLaunched(LaunchActivatedEventArgs args)
         // writes the answers to a file and exits. See Diagnostics.cs.
         string[] arguments = Environment.GetCommandLineArgs();
 
-        int flag = Array.IndexOf(arguments, "--diagnose");
-        if (flag >= 0 && flag + 1 < arguments.Length)
-        {
-            diagnostics = new Diagnostics(arguments[flag + 1]);
-            diagnostics.Run();
-            return;
-        }
-
-        flag = Array.IndexOf(arguments, "--screenshot");
+        int flag = Array.IndexOf(arguments, "--screenshot");
         if (flag >= 0 && flag + 1 < arguments.Length)
         {
             ElementTheme theme = arguments.Contains("dark")