Detect repo re-creation

[MoralCode]

As a result of discusion in #93, we have identified general issues with collection as it relates to moved/changed repos

this issue happens when:

1. a github repo has been collected on
2. the underlying github repo is Deleted (not moved or renamed)
3. the underlying github repo is replaced with a new repo at the same URL
4. Collection runs again

This will pass right through our current repo move detection unnoticed because the same URL is still valid and no redirect will happen.

a specific, non exhaustive list of things that happen as a result:

• attempts to collect on that new repo will fail with an error related to duplicate URLs when collecting pull requests (this is Collect_pull_requests : IntegrityError('(psycopg2.errors.UniqueViolation) duplicate key value violates unique constraint "pull-request-insert-unique" #93)
• presumably the same thing happens with issues too (collectoss.tasks.github.events.collect_events: duplicate key value violates unique constraint "issue-insert-unique" #151)
• Facade seems to happily clone the new repo - potentially overwriting the previous repo (and creating inconsistent state)

[MoralCode]

criteria for Resolution/closure of this issue:

1. the move detection task needs to also check for the src_id matching on each run (If it doesnt match, the repo needs to be tombstoned, just like when a 404 is detected, and a new repo needs to be created to collect the new information.)
2. The uniqueness constraint on PR's also needs to be dropped

These changes will explicitly create a situation where non-unique PR urls are present in the DB. I suspect this will have an impact on data handling, so maybe we need to explicitly leave ignored repositories out of materialized view computations/the REST API or other downstream-facing interfaces