Site: Improve challenge transfer edge cases

[ConnorNelson]

Challenge transfer logic has some interesting edge cases, this PR seeks to clarify them a bit.

In particular, the edge case that led to this PR is the case where someone creates a challenge, then realizes what they actually wanted to do was transfer a challenge. Under the current logic, the transfer will not happen because the challenge already exists, and so it will never enter the transfer logic. Transfer logic should take priority.

However, if there is an existing challenge, we have to be careful, and have some options:

• Refuse and throw an error
• Orphan the existing challenge (this gets complicated fast)
• Delete the existing challenge
• Delete the existing challenge, but only if there are no solves, otherwise refuse and throw an error
• Merge the challenges (e.g., the solves)

For now, we will just refuse and throw an error.

[ConnorNelson]

Probably long-term what we need is to separate this sort of capability out of the yml. The yml should only define all the challenges, descriptions, order of them, etc. It should not depend on / more seriously interact with the state of a particular deployment of the dojo.

Instead, state management like this should happen either directly on the site, or using some dojo command(s) while in the infrastructure, whether it is renaming an id, or deleting solves, or merging solves of two challenges together into one challenge, etc.