Swap FK merge_trains.pipeline_id to ci_pipelines for LFK

What does this MR do and why?

Per &7249 (closed)

As part of our CI "decomposition" efforts we need to remove all foreign keys that are cross-database (ie. between the planned main and ci databases). We are going to replace them all with "loose foreign keys".

Related: #348272 (closed)

Validations

• Best team to review (check off when reviewed): @fabiopitino grouppipeline execution devopsverify
• No way for user to access once parent is deleted. Please explain: Since we use merge_train.pipeline, it will return nil if not found by ID. If pipeline is deleted in the meantime. The merge train will recreate one for the same MR.
• Possible to access once parent deleted but low user impact. Please explain: By design, merge trains could miss pipelines in its dynamic state, and the design is shared across backend and frontend, thus nil checks are placed by default.
• Possible Sidekiq workers that may load directly and possibly lead to exceptions. Please explain: Explained above. We don't expect null exceptions since it's nullable by design.
• Possible user impact to be evaluated or mitigated. Please explain: MergeTrains::RefreshWorker could try to access the pipeline object through merge_train object. One edge case could be that the nullify happens after the existence check and fetch. Technically speaking, it might negatively affect the race condition due to its latency, however, the consequence of the stale evaluation should be very rare since pipeline deletion itself is very rare and requires proper authorization to perform the action.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.