v0.25.0 — checking its own claims

A documentation release, and every item in it is this project checking its own
claims rather than adding new ones. Two published allocation ratios were stale, one
of them flattering by 2×; a test count corrected yesterday was stale again today;
and the rule that catches all of this finally got written down instead of being
folklore in a test-file header.

Fixed

• The published test count goes stale by construction, so it is now a floor. It
  read 480 for several releases after it stopped being true, was corrected to an
  exact 584 — and was stale again within a day. It now reads "over 600" with the
  command to count them, for the same reason v0.19.0 deleted the hardcoded "latest
  version" from the docs page rather than updating it. A floor can only ever become
  an understatement.

• Two stale allocation ratios in BENCHMARKS.md. Add into
  a growing book was published as 1.05 allocs/op against a measured 2.01 — the
  page understated the cost of growing a book by half, which is the third correction
  this file has taken and the third in the flattering direction. Cancel + replace
  read 0.009 against a measured 0.0000, understating the engine instead.

  Neither is a regression: both reproduce identically on pre-session code. Both are
  deterministic allocation counts rather than timings, and both are printed by
  pkg/orderbook/alloc_test.go on every run — the figures were in the test log the
  whole time and nobody re-read them.

• Config.ShardIndex moved to the end of the struct. Appending cannot shift the
  offsets of fields the match path reads; inserting can.

Added

• TESTING.md — the rule the rest of the documentation rests
  on, written down: a test does not count until it has been run against code
  deliberately broken in the way it claims to detect. It was already the standing
  rule for the replication drills, whose file header names the sabotage each was
  verified against; this generalises it, because the same mistake has now been made
  six times across five tests, in code written carefully by people who knew about
  the rule.

  The case studies are the point, and they are all from this repository: a digest
  test satisfied by a sequence counter, a checksum test satisfied by a magic number,
  a timing test that first passed against a short-circuit and then failed against
  correct code, a drill that blamed the wrong follower, and a test double more
  permissive than the venue it stood in for. Each read correctly and would have
  passed review. Linked from CONTRIBUTING's quality bar, where it changes what a
  contributor is asked to have done rather than merely believed.

---

Upgrading: nothing to do — documentation and one struct field reordering, no API or wire changes.

Full changelog: v0.24.0...v0.25.0