Add safety check to repair that prevents deleting unknown new backups

[Jojo-1000]

If any dlist files have a newer timestamp than the last database backup, the repair is aborted before remote files are deleted. This prevents data loss like in #4579, when an outdated version of the local database is used with a newer remote backup.

This affects both the CLI and GUI repair operations. An override is not provided. The user has to delete the additional dlist files manually if the data loss is intended. After that, leftover dblock files are cleaned up as usual.

Steps to reproduce error:

• Create a backup
• Make copy of database
• Change files in backup and create a second version
• Replace database with old copy
• Run backup results in an error message that prompts to repair

Current behavior:

• Repair finds additional files on the remote and deletes them
• The second version of the backup is lost

New behavior:

• Repair checks that newer backup version exists and results in an error:
  The remote files seem to be newer than the local database. Repair would cause data loss. Run recreate instead if the remote files are not corrupted.
• The user has to run a database recreate
• No data is lost

I am not sure whether the new error message needs to be translated or not (most others in the repair command do not seem to be).

[duplicatibot]

This pull request has been mentioned on Duplicati. There might be relevant details there:

https://forum.duplicati.com/t/duplicati-database-recreate-running-for-a-week/16651/86