Correctly identify which secondary indexes need to be updated during a merge

[nicktobey]

Some columns in a table have a different encoding when used in a secondary index key: mainly TEXT and BLOB types are an address encoding in the primary index, but when used in a secondary index (with a length prefix), the prefixes get stored in the secondary index as an inline encoding.

We have a check during merge that determines whether or not we need to rebuild a secondary index from scratch instead of simply merging in changes from the other branch. This is necessary because in fringe situations, a row that did not change on the other branch's primary index did change on the other branch's secondary index. This happens when the other branch changed the secondary index's schema, such as dropping or adding columns, changing a length prefix, etc.

In these situations, it is not safe to simply diff the primary indexes and update the changed rows in the secondary index.

When I originally wrote this check, I compared the schema of the merged table's index with the original table's index to determine whether the other branch introduced a change. However, I deliberately ignored things like the TEXT special-treatment when doing this check. The motivation for doing it this way was to ensure that if the other branch changes a TEXT type to a VARCHAR type (or vice versa), we will still detect this change even though the encoding of the index doesn't change.

In practice we don't need to worry about that, because such changes still get detected and handled correctly elsewhere in the merge process. And the check as written is incorrect, and leads to situations where if the merger erroneously concludes that an index will be dropped and rebuild, and thus doesn't update it during the merge.

This PR fixes the logic of the check and adds additional tests to verify that the merge behavior is still correct.

[coffeegoddd]

@nicktobey DOLT

comparing_percentages
100.000000 to 100.000000

version	result	total
7d6f719	ok	5937471

version	total_tests
7d6f719	5937471

correctness_percentage
100.0

[coffeegoddd]

@nicktobey DOLT

comparing_percentages
100.000000 to 100.000000

version	result	total
5a9d002	ok	5937471

version	total_tests
5a9d002	5937471

correctness_percentage
100.0