Split CI/CD-related infrastructure into its own model

[dogboat]

Description

This PR splits CI/CD-related infrastructure (scm/build/orchestration servers) out of the Tool_Configuration model into its own CICDInfrastructure model. Engagements are updated with new fields to point to the new model; the old fields are dropped.

The migration creates CICDInfrastructure objects from existing Tool_Configuration models used by engagements and populates the new fields on each engagement accordingly.

[sc-12921]

[valentijnscholten]

This looks OK at first sight. Some thoughts:

• dojo/models.py also contains some logic around scm_type, mainly to construct urls to commits. Should this be harmonized/included here as well? Maybe in a follow-up PR?
• The engagement API changes should probably be mentioned in the upgrade notes. According to Mr Claude:

Breaking API change: Engagement cicd server fields

EngagementSerializer uses exclude = ("inherited_tags",), so it auto-reflects model fields. This PR removes the old engagement FKs and adds new ones, changing the Engagement payload in a backward-incompatible way:

Before	After
build_server	cicd_build_server
source_code_management_server	cicd_scm_server
orchestration_engine	cicd_orchestration_engine

Three things break for existing clients:

• Field names renamed → old keys rejected as unknown / absent on read.
• Target model changed: values were Tool_Configuration IDs, now CICDInfrastructure IDs — same integer, different object. A client that hardcoded a tool-config ID now points at the wrong row or a non-existent one.
• Validation: new FKs use limit_choices_to={"infrastructure_type": ...}, so posting a cicd_build_server ID whose type isn't build_server is rejected — a new constraint that didn't exist before.