Phase 1 - Make LFKs compatible with cells

What does this MR do and why?

Make LFKs compatible with cells

As per the discussion about making the LFKs compatible with cells, we decided to split the LFK deleted records table into 5 new tables, one per sharding key and an extra table for cell local records. This represents Phase 1 (architectural change).

This MR adds 4 new tables, which will be used to map sharded records to their corresponding table based on the record sharding key: organization_id, namespace_id, project_id, or user_id.

Phase	MR
1 - Foundation	This MR
2 - DeletedRecordStore	-
3 - Trigger function update + first table rollout	-
4 - Gradual trigger rollout	-
5 - Cleanup	-

About the changes

This is the initial change that aims to:

1. Create 4 new partitioned tables, one per sharding key type: loose_foreign_keys_organization_deleted_records, loose_foreign_keys_namespace_deleted_records, loose_foreign_keys_project_deleted_records, loose_foreign_keys_user_deleted_records, with a initial partition.
2. Move the LooseForeignKeys::DeletedRecord model methods to a shared concern, DeletedRecordConcern.
3. Move the LooseForeignKeys::DeletedRecord specs to a shared example to be used by all new models.
4. The current LFK behavior remains unchanged, working as usual through LooseForeignKeys::DeletedRecord.

Related #597949