Handles migration case where an expected constraint is renamed but the constraint does not exist

[AndyButland]

Prerequisites

• I have added steps to test this contribution in the description below

Fixes: #17855

Description

We have a migration as part of the 13.3 release that amongst other things attempts to rename a constraint. It fails if the constraint doesn't exist. It's not obvious why the constraint shouldn't exist, but must be possible via some upgrade scenarios as it's been seen in the wild.

When this PR is merged the migration will no longer fail, and will create the constraint if it doesn't find it rather than attempting to rename it.

To Test:

• Wind back the migration history of an Umbraco 13 site running on SQL Server with:

update umbracoKeyValue
set value = '{6158F3A3-4902-4201-835E-1ED7F810B2D8}'
where [key] = 'Umbraco.Core.Upgrader.State+Umbraco.Core'

• Remove the constraint you should already have on umbracoContentVersion.versionDate with:

ALTER TABLE [dbo].[umbracoContentVersion] DROP CONSTRAINT [DF_umbracoContentVersion_versionDate]
GO

• Before the PR is merged you'll get the reported error when starting up Umbraco and triggering the upgrade.
• After the PR the migration should complete and you'll find the constraint created:

[Migaroez]

Looks good and works as described