Backup/restore: backup sync --move-store, --forget-store, --forget-backup #820

The store-maintenance options of design section 4(g) and the PR 10 section (#396), the second of the three PRs the design's PR 10 ships as:

• backup sync --move-store <old root> re-points the rows of an old store root to the configured store after the tree was copied there. It first resolves the old root's CREATING and DELETING rows against the configured store, stops on a row whose data files were not all copied, and refuses a DELETING, DELETED or FAILED row whose copied prefix holds a verified manifest.
• backup sync --forget-store <root> removes the catalog rows of a store root that is gone, deleting no bytes.
• backup sync --forget-backup <arn> removes one backup's row, deleting no bytes. It refuses a CREATING row with a live owner. This is also the way out for a catalog restored from a database backup whose newest AVAILABLE backup was deleted after that backup was taken: the store stays unhealthy ("manifest probe failed") and --prune-missing refuses while it is.
• BackupCatalog::list_backup_rows_by_root and rewrite_store on all four backends, and the full report of the rows of other roots in plain backup sync.

Every option takes the maintenance claim, and on SQLite the serve lock, as --prune-missing does. No deletion duty acts on the bytes of a row the operator forgot (4(a)).

Phase 1 of the design, so a 1.0 requirement. Part of #624. Depends on PR 10 (#746, #825) and stacks on PR 11 (#747, #855).