Fix versioning and start the changelog

[iderex]

Once there is a downloadable artefact there are people running versions of it, and
the two questions they will ask are which version they have and what changed. Both
need answering before the first release rather than after, because a versioning
scheme adopted at version four leaves three versions nobody can place.

Fix three things.

The version the binary reports comes from the tag it was built from, injected at
build time rather than written in a source file. A hand-maintained version constant
disagrees with the tag eventually, and it disagrees silently, which makes every bug
report from that version misleading.

A changelog with an entry per release, saying what changed and what it means for
somebody upgrading. This board is allowed to break its own tool between versions,
since nothing is supposed to depend on it, and that permission is exactly why the
changelog has to say when it happened.

A stated compatibility position, which is not a promise of stability but a
statement of what it is not. Something along the lines of: the record format may
change, a change that invalidates existing records will not be made silently, and
the changelog is where it is announced. That is honest for an experimental board and
it is more useful than a version number implying guarantees nobody intends to keep.

Done when the binary reports a version derived from its build tag, CHANGELOG.md
exists with an entry for the first release, and the compatibility position is
written in the changelog or the operator guide.

[iderex]

One of the three is done. The compatibility position is in
docs/operator-guide.md on the default branch as of e5067b1, which is one of
the two homes this issue allows it, and it points at
docs/decisions/0013-how-the-record-format-changes.md rather than restating
what that record says:

git grep -n '0013-how-the-record-format-changes' origin/main -- docs/operator-guide.md
origin/main:docs/operator-guide.md:204:[docs/decisions/0013-how-the-record-format-changes.md](decisions/0013-how-the-record-format-changes.md),

It says the format may change, that a change is decided in a record and not made
silently, and that today the record that decides it is the announcement, there
being no changelog. That last sentence moves to the changelog when this issue
lands one rather than being copied into it.

The other two clauses have nothing to write against. A changelog needs an entry
for the first release and there is no release, and a version derived from a
build tag needs a tag and the workflow that injects it at build time. Both sit
behind the release, which is #41 and #45, and behind entry four of #46, since a
board that publishes nothing has no artefact for a version to be reported by.