Three Way Merging won't consider a row to have a data conflict if both sides of the merge have the same binary representation.

Steps to reproduce:

```
git checkout nicktobey/schemamergetests
go test libraries/doltcore/merge/schema_merge_test.go -run "^\QTestSchemaMerge\E$/^\Qcolumn_add\E$/^\Qdrop_tests\E$/^\Qmerge_left_to_right\E$/^\Qleft_side_column_drop\E$/^\Qone_side_sets_to_NULL,_other_drops_non-NULL\E$"
```

In the test in question, the base of the merge has one value for a column (3), the left side drops the column, and the right side sets the value of that column to NULL. This should be a data conflict.

However, when the merge is performed, no data conflict is detected, and the branch is dropped.

I suspect this is a result of the way we represent tuples in storage: we want to optimize for the case where the user adds a new NULLable column. We do this by omitting any trailing NULLs in the tuple: thus, adding a nullable column does not change the representation of any existing rows and the table does not need to be rewritten.

However, as a consequence of this, the left and right sides of the merge now have the same binary representation. I suspect that the differ compares the binary representations, sees that they're equal, and assumes that any changes are convergent and can't conflict.