Name the rules, say when there is nothing to say, and hold a baseline

Four things SplitLint wanted, and they build on each other.

EVERY WARNING NAMES ITS RULE, in brackets at the end the way a compiler
names the flag that produced it. Twelve rules, listed by --help. That makes
the other three possible: suppressions can name one rule and leave the line
honest about the others, the harness can assert on a rule's identity rather
than on the wording of its message, and --machine can print one tab
separated line per warning - file, line, rule, message, help - so nothing
downstream reads prose. This file's own output was parsed with regular
expressions three times in one day before it had a shape to rely on.

A CLEAN RUN SAYS SO:

  No style warnings: 121 files checked against 12 rules.

It used to exit in silence, which does not tell you it found nothing - it
tells you nothing at all, and from outside the two are identical.

A MARKER THAT SILENCES NOTHING IS ITSELF REPORTED, as dead-suppression. An
exception that outlived whatever made it necessary is the thing the
required reason exists to prevent, and naming the wrong rule now gets you
both the warning you meant to silence and a note that your suppression is
doing nothing.

AND THE CORPUS IS HELD TO A BASELINE. Sixty one warnings are left in it
deliberately and nothing stopped a sixty second. Tests/lint-baseline.txt
records how many of each rule each file should produce, so a new one fails
make test while the sixty one stay quiet; confirmed by adding an INIA 0d0
to Say.asm and watching it name the file, the rule and the count. It counts
per file and rule rather than recording line numbers, because line numbers
would churn the whole baseline whenever anything was inserted above a
warning - the same reason cycle counts are stripped from recorded output
here. ./Tests/lint.sh --bless records it again.

One thing to know for next time: the rule name was inserted before the line
number at all twenty one call sites, and the signature was changed to match
rather than the twenty one call sites being fixed. (path, rule, line) reads
no worse than (path, line, rule) and one edit has fewer ways to go wrong
than twenty one.

README.md

@@ -176,7 +176,17 @@ Without `-o` the output takes the source file's name, in the directory you calle
 ## Checking Assembly: SplitLint
 
 ```
-./SplitLint [--fatal-warnings] <sourcefile> [sourcefile ...]
+./SplitLint [--fatal-warnings] [--machine] <sourcefile> [sourcefile ...]
+```
+
+**Every warning names the rule that produced it**, in brackets the way a compiler names a
+flag, and `--machine` prints one tab-separated line per warning and nothing else - file,
+line, rule, message, help - so that nothing downstream has to read prose. A run that finds
+nothing says so rather than exiting silently, because a tool that says nothing has not told
+you it found nothing; it has told you nothing at all, and from outside those look the same:
+
+```
+No style warnings: 121 files checked against 12 rules.
 ```
 
 SplitLint reports valid assembly that has a shorter direct expression, beginning with
@@ -208,8 +218,19 @@ required.** A suppression with no explanation is a way to make a tool quiet rath
 way to say something, and a bare marker is refused rather than honoured. The corpus has
 three of them, all in test programs: `branchTest.asm` exists to check that a branch whose
 carry is known behaves correctly, so a diagnostic saying the outcome is known is exactly
-right and exactly unwanted. Suppressions are counted and reported at the end of a run, so
-that the claim they make is visible rather than silent.
+right and exactly unwanted. `splitlint[rule]: <reason>` silences one rule and leaves the
+line honest about the others.
+
+Suppressions are counted and reported at the end of a run, and **a marker that no longer
+silences anything is itself reported** - an exception that outlived its reason is the thing
+the required reason was meant to prevent.
+
+**The corpus is held to a baseline.** Sixty one warnings are left in it on purpose, and
+`Tests/lint-baseline.txt` records how many of each rule each file is expected to produce,
+so a sixty second fails `make test` while the sixty one stay quiet. It counts rather than
+recording line numbers, because recording lines would churn the whole file whenever
+anything was inserted above a warning. `./Tests/lint.sh --bless` records it again once
+warnings have been deliberately fixed or deliberately accepted.
 
 The same local model tracks whether carry is known set or clear. It reports a redundant
 `CCF`, a `BRC` or `BNC` whose outcome is already determined, and computes carry through