Handle database/filesystem conflicts (due to incorrect backup/restore) more gracefully

Original summary: "Add check on creating/deleting a Repository"
Hi.
On my Backup/restore tests I wanted to find out what happens if I do this backup "online" (hot-backup).
I found out that always the database has the main knowledge of the system configuration and it seems only the filesystem (stash_home) knows some extra informations about plugins and repositories.

In a scenario where you create a database backup followed by the backup of stash_home within a huge (unnatuaral) period of time you can describe following case:
if you create a repository within this time, it comes that if you restore that backup - this repository is gone. This is okay as at the time of the database backup the repository was unknown. But sadly this repository exists in the stash_home filesystem. First nobody knows BUT:
If you now try to create a new Repository on this restored system you get an error: stash says the reppsitory "repoID" (it's the repo-id-number) would exist... Looking into the filesystem you will see this repo existing...

I came to the conclusion that Stash iterates by 1 when creating a new repository...
I'd like to ask you to improve that by checking first if a repo with the next iteration already exists and suggest to create a new repository with one more iteration. Also put a big warning that it seems there is a "ghost-repository"
this would not paralyze our users from creatign repositories when having a huge stash-instance later

You can imageine that there is obviously the same counter when deleting a repository within that timespan.

Maybe as a spanning view I'd suggest to store some metainformation (which stash-project, wich repo-name) inside the bulk-repository on the filesystem. (I'll look for an open issue for that or open another one later)

Thanks!