Hashed Storage Migration: Handle failed attachment migrations wth existing target path

After some investigation on a few failed migration cases that we saw, when running the Hashed Storage migration ourselves on GitLab.com, we identied one unhandled pattern:

1. An existing project, gets its project migrated
2. It proceed to migrate the attachments, and fail with Projects::HashedStorage::AttachmentCannotMoveError

I suspect this was due to previous attempts, which we probably fixed the cause of the failure already, but left some garbage behind.

I saw no existing files there, only the tmp/cache and tmp/work folders that are created by Carrierwave at some point in time.

Fix proposal

The idea is to be conservative on the solution, and instead of just removing the main folder, which should be a workaround, we should consider ignoring the fact the folder exists, if only this tmp folder is inside it.

By not removing anything we reduce the possibility of a bug leading to data-loss.