Gracefully recover from previously failed rebase

Zendesk: https://gitlab.zendesk.com/agent/tickets/42902

It appears that we are unable to gracefully recover from a previous failed rebase. The temp files will still be around and we throw an error on subsequent rebases:

October 11, 2016 15:15 -> ERROR -> Failed to clone repository for rebase:
October 11, 2016 15:15 -> ERROR -> fatal: destination path '/var/opt/gitlab/gitlab-rails/shared/tmp/rebase/63/1305' already exists and is not an empty directory.
October 11, 2016 15:16 -> ERROR -> Failed to rebase branch:
October 11, 2016 15:16 -> ERROR -> error: Cannot pull with rebase: You have unstaged changes.

We should be able to detect a failed rebase, clean the files, and allow future rebase tries. For now I've asked the customer to try manually removing the temp files.

@vsizov Any ideas about the best way to handle this?