Add reverse_lock_order to migrations adding foreign keys
What does this MR do and why?
This MR updates the three migrations from !205992 (merged) to use reverse_lock_order: true when adding and removing foreign keys.
Since merge_requests, projects, and users are high-traffic tables, using reverse_lock_order helps avoid potential deadlocks by acquiring locks in the reverse order (target table first, then source table).
Additionally, all three migrations have been moved from db/migrate to db/post_migrate.
Edited by Reuben Pereira