Deleting and renaming a GitHub team gives it a new GitHub ID, which causes uniqueness constraint violations

[carols10cents]

Related but slightly distinct:

• Deleting a team results in a 500 because of a uniqueness constraint violation #4281
• Can't remove deleted organizations from crate owners #1818
• Duplicate key value violates unique constraint "teams_login_key" #4252

To reproduce:

• Create a github team in an org and run cargo owners --add github:org:team to add the team as an owner of the crate.
• Delete the team in github and recreate it with the same name. This should give the team a new github ID.
• Attempt to add the team to a different crate, issuing the same cargo owners --add github:org:team command.
• Crates.io will return a uniqueness constraint violation because we enforce unique team names.

If we get the same ID but a different name, we upsert and update the name. But we aren't doing that for teams. I think as long as the org's github id is the same (that is, the entire organization hasn't been deleted and recreated), it isn't a security problem if we update the team ID when the names are the same (as it indicates the same organization has deleted and recreated the team).

[nic-hartley]

Ah. Hm. I think I noticed this while working on #7051 and then I dismissed it because, surely, if it was an issue, it'd have already been noticed, so it can't be that big a deal. Whoops.

The consensus there was that the status quo is not a security issue because we're reusing the org ID rather than the name, yep. But it's still a usability issue of not being able to reuse org names.