fix(deletions): Fix MonitorIncident FK to MonitorCheckIn cascade

[yuvmen]

While these FKs are supposed to have CASCADE on them according to our models, they are in fact not in the DB. Trying to run this to force them to be CASCADE in production

[github-actions]

This PR has a migration; here is the generated SQL for src/sentry/monitors/migrations/0013_fix_monitorincident_checkin_cascade.py

for 0013_fix_monitorincident_checkin_cascade in monitors

--
-- Alter field starting_checkin on monitorincident
--
-- (no-op)
--
-- Alter field resolving_checkin on monitorincident
--
-- (no-op)

[markstory]

This isn't generating any SQL in CI, and it might not generate any SQL in production either as django's state before this migration is run indicates that the on_delete action is already present. If you use a SeparateDatabaseAndState operation instead you could rebuild the constraint via SQL to ensure that the constraint is created to match django's state.

[yuvmen]

I notice that we actually do this across the board, that our FKs have Cascades at the django level but not in the DB generally. I think I will solve this in the more canonical way of deleting the child relations manually using a deletion task instead of letting the DB do it, which seems like we dont usually do.

[yuvmen]

Will solve this through manual deletion of child relations, not by changing the way we work with DB foreign keys.