repository: Implement atomic locking semantics for RemoveRepository

The RemoveRepository RPC does not have atomic locking semantics. First, it does return success in case the repository does not exist, which doesn't give the caller the ability to detect that the expected state doesn't match the actual state. And second, it doesn't lock the repository before removing it. While this cannot remove contents of a repository which is being concurrently created as soon as atomic support for repository creation has fully landed, it can still happen that we remove contents of a repository which we're just about to rename via the RenameRepository RPC.

Fix this by implementing the same locking support as we now have for all the other RPCs which create or rename repositories. Like this, it's impossible to remove a repository whose location is about to change anyway such that above race cannot exist anymore. Furthermore, in accordance to the changes we've performed for the other RPCs, this RPC will now start to fail in case the repository doesn't exist at all anymore.

Changelog: fixed