Merging an altered column with a deleted row currently results in a merge conflict.

[nicktobey]

dolt sql -q "create table tableA (id int primary key, col1 varchar(255))"
dolt add .
dolt commit -m "new table"

dolt sql -q "insert into tableA values (1, 'test')"
dolt add .
dolt commit -m "new row"
dolt branch revert_target

dolt sql -q "ALTER TABLE tableA MODIFY col1 TEXT"
dolt add .
dolt commit -m "change col"

dolt revert revert_target

Expected behavior: revert succeeds: the added row is removed from the table.
Observed behavior: operation fails with revert currently does not handle conflicts

This is similar behavior to #6660: a merge has an intuitive expected result, but the differ reports a conflict anyway.

The reason why the differ considers this a conflict is because it detects that a row is removed in one branch, and that row's binary representation is modified in the other branch. However, intuitively we expect this merge to succeed because the semantic meaning of the row has not changed: only its representation.

With #6660, we decided that the differ should take this into account. We fixed that issue by updating the implementation of valueMerger.processColumn to convert values to the type specified in the merged schema in order to determine whether the values themselves have changed (as opposed to just their representation on disk.) Unfortunately, that fix does not prevent this issue because this conflict is detected before processColumn is ever called. The differ itself needs to be aware of the schema on each branch and convert as needed to detect conflicts. If written correctly, this shouldn't have a performance penalty: we will only be doing these conversions in places where we previously would have just assumed a conflict.