Fix Mismatching constraint names in old migration

[Migaroez]

Prerequisites

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

Fixes #16267

Description

Due to older versions of Umbraco not always having had explicit constraint names, some older databases have "system-named constraints" resulting in constraint names not matching up what what we expect in later versions.

This PR takes that behavior into account to change a prior migration that relied on the constraint name being a fixed value. By utilizing the know table name, column name and constraint type (default, which only exists ones per column) we can identify the constraint without relying on it's name.

Testing

Since it is not straight forward to get a DB in a state where it used system-named constraints, I have asked the community to test out this PR on their DB's

I have also tested on the following scenarios to cover as many meaningful permutations as possible.
SQL used to rename the constraint to a bogus one
EXEC sp_rename N'DF_umbracoContentVersion_versionDate', N'DF_umbra#125498', N'OBJECT';

• test on db mentioned in issue (by the community)
• test on a v10 db where the constraint in question was manually renamed
• test on brand new db
• test on v12.latest db
• test on v10.tatest db
• test on v13.0 base db

[Zeegaan]

Looks good, tests good 🚀