Bug fix: Allow unresolved FKs to merge with resolved FKs

[fulghum]

Dolt foreign keys can be in a "resolved" or "unresolved" state. A resolved FK has resolved the table and columns it references, and contains unique identifiers for the referenced columns. An unresolved FK only knows the table and column names that it references. Because of these two states, the way Dolt matches FKs differs depending on whether each key is resolved or unresolved.

Dolt has logic (ForeignKeyCollection.GetMatchingKey()) to match a resolved FK with an unresolved FK, but this function didn't support matching an unresolved FK with a resolved FK. That code assumed that the ForeignKeyCollection would always be from an ancestor root value and therefore it wasn't valid for the ancestor to be resolved, while a more recent root value was unresolved. However, since then, we have used this logic in our root merging logic that breaks that assumption.

In a multi-session environment, one client can create a table with an unresolved FK, then a second session can load that table, resolve the FK, and commit the changes to disk. If the first session still contains references to the unresolved FK, then when it goes to commit, Dolt's merge logic wasn't able to match the unresolved FK in the session with the resolved FK that was written to disk, and the FK constraints were silently dropped from the new table version.

This PR adds a new parameter to ForeignKeyCollection.GetMatchingKey() to allow the caller to control whether a resolved FK should match with unresolved FKs or not. This means ForeignKeyCollection.GetMatchingKey() doesn't have to assume its receiver instance is a ForeignKeyCollection from an ancestor root value, and instead the caller is responsible for specifying which behavior is needed.

Related to #7956

[github-actions]

Additional work is required for integration with DoltgreSQL.

[coffeegoddd]

@fulghum DOLT

comparing_percentages
100.000000 to 100.000000

version	result	total
8a6c868	ok	5937457

version	total_tests
8a6c868	5937457

correctness_percentage
100.0

[Hydrocharged]

LGTM! It's failing integration with Doltgres, so that needs to be investigated.

[zachmu]

This is fine for a customer fix.

But the fact that we have two different byte-incompatible representations for foreign keys depending on what statements have been run previously is bad on multiple levels. It breaks history independence. It produces an invisible schema diff. And it leads to really weird bugs like this one.

A better design would be to serialize foreign key constraints identically in all cases, and always resolve them as part of analysis. Can you please file an issue so we don't lose track of this work?

[coffeegoddd]

@fulghum DOLT

comparing_percentages
100.000000 to 100.000000

version	result	total
2dd2946	ok	5937457

version	total_tests
2dd2946	5937457

correctness_percentage
100.0

[fulghum]

Added tracking issue for the larger work to clean up FK resolution: #7982