Backup/restore: backup migrate-legacy #821

extenddb backup migrate-legacy <arn>|--all (design section 3 and the PR 10 section, #396), the third of the three PRs the design's PR 10 ships as. It streams an in-catalog (legacy) backup through the frozen legacy reader, checking each item with the backup job's item validator, into the store under the legacy backup id, so the ARN survives, with a manifest whose snapshot.kind is legacy_in_catalog. Before it inserts the AVAILABLE row or deletes anything it re-reads the manifest it wrote and checks the item count; only then does it insert the row and delete the legacy rows. It refuses a backup, keeping its legacy rows and deleting the prefix it wrote, when the id carries no instant, when the validator refuses an item, or when it cannot state the definition (a pre-0.0.4 SQLite backup); the manual's way out for such a backup is a restore and a new backup.

Phase 1 of the design, so a 1.0 requirement: PR 14 (#749), one minor release after 1.0, refuses its migration while any legacy backup row exists and names backup migrate-legacy --all, so 1.0 must ship the command. Part of #624. Depends on PR 10 (#746) and stacks on #820.