Lay out the repository, and give a fresh clone two commands that work

[iderex]

Somebody who clones this repository today can build nothing and run nothing.
Before any of that can be true there has to be a layout, and the layout is worth
one decision rather than eleven accidents.

The test of a good answer is short. A person who has never seen the repository
runs two commands from README.md and both succeed on a clean machine with only
the pinned toolchain installed.

What this issue produces

A directory layout with one directory per concern from the boundary record in #3,
so that the boundary is visible in the tree rather than only in a document.

One command that builds everything and one that runs every test, both named in
README.md and both used verbatim by the gate, so the gate and a contributor run
the same thing.

A note in README.md saying what a fresh clone needs installed and nothing more.

Done when

README.md names the two commands. Both succeed from a clone with no state left
by a previous build. The gate workflows added in this milestone invoke those same
two commands rather than their own variants. Blocked on #11.

[iderex]

Two landed records name this issue, and between them they put an obligation on it
and a constraint on where it may write, neither of which is in the list above.
Read at e5a513c23f9bc6a0ddedc7b52bb299ae5d0cee05.

git grep -l '#13\b' -- docs
docs/decisions/0009-the-concurrency-model.md
docs/decisions/0064-the-numbers-the-core-does-not-report.md

The obligation. docs/decisions/0009-the-concurrency-model.md states its
reentrancy and thread-safety rules per kind of object because there is no type
here to attach them to, and it says where the attaching happens:

sed -n '188,191p' docs/decisions/0009-the-concurrency-model.md
## Reentrancy and thread safety, by kind

No type exists in this repository yet, so this is stated per kind of object. The
names arrive with #11 and #13, and each type carries the statement for its kind

So the layout this issue produces is where a kind of object stops being a kind
and becomes a name, and the record expects each of those names to carry its own
thread-safety statement where a reader will meet it rather than only in the
record. The list above asks for one directory per concern and stops at the
directory. A layout that satisfies every word of it can still leave 0009's
statements attached to nothing, and the failure is silent: the record goes on
being true and correct, and the reader who meets a handle in the tree meets no
statement about which thread they may call it from.

The constraint. docs/decisions/0064-the-numbers-the-core-does-not-report.md
declines to write a paragraph into README.md, and the reason it gives is about
this issue:

sed -n '129,131p' docs/decisions/0064-the-numbers-the-core-does-not-report.md
`README.md` is not that place either, and not only for the reason above. It is
where #13, #23 and #74 also write, and a paragraph added here to close a
condition would be the fourth hand in one file.

Two of this issue's three conditions land in that file, the two commands and the
note about what a fresh clone needs installed. #23 has to name every command the
gate runs, and #74 writes what an operator reads about their data. So the file
this issue writes its result into is one three open issues have a claim on, and a
record has already refused to add a fourth paragraph there for that reason.
Nothing about that is settled here, and it is worth knowing before the file is
written rather than at the moment two changes meet in it.

What is in the tree today, so the comparison is against a reading rather than an
impression:

git ls-files | wc -l
68
git ls-files | grep -v '^\.' | grep -v '^docs/' | tr '\n' ' '
DCO NOTICE.md README.md

No directory in that list is a concern from the boundary record, so the layout
half of this issue is untouched, and I have built none of it. I have changed no
condition and no scope.