Add option to reverse locks for `remove_foreign_key_if_exists`

In !67448 (merged), we added an option to add_concurrent_foreign_key that can reverse the lock order by manually executing a LOCK TABLES statement before trying to add the foreign key. The reversed ordering can decrease the likelihood of deadlocks when adding foreign keys between busier tables, because it locks the tables in an order that is more likely to align with application locking patterns.

We should add a similar option to remove_foreign_key_if_exists, which we generally use whenever dropping a foreign key.

We should also consider making this option defaulted to true for both helpers.