Transactionality of project renames and removals
As noticed by @madprog in the discussion about !16 (merged), it is possible that the atomicity of our implementation of rename / remove could be improved.
In any case, I'm in favour of hiding in the inner gitlab-shell repo-neutral command.
I decided to merge !16 (merged) right away because I felt that the current state (systematic half-move) was worse in all cases. This issue to track that it's probably non optimal