fix: fix convergent add columns being flagged as conflicts

[tanyongzhi]

When both branches run an identical ALTER TABLE ... ADD COLUMN with a
DEFAULT, Dolt was incorrectly flagging the merge as conflicted and
(under autocommit) silently rolling back any DML the side branch made
on the new column.

Two bugs were responsible:

1. checkSchemaConflicts (merge_schema.go) unconditionally appended a
   NameCollision conflict whenever a column existed on both sides but
   not in the ancestor, without first checking whether the definitions
   were identical. Added an ours.Equals(*theirs) guard so convergent
   adds are recognised as conflict-free, consistent with mergeColumns
   which already handled this correctly.

2. processColumn (merge_prolly_rows.go) treated any divergent values
   for a column absent from the base as a conflict, even when one
   side's value was simply the schema-backfill default. Added
   getConvergentDefault, which evaluates the column's default
   expression at conflict-check time and uses the result as a synthetic
   base: a side whose value equals the default made no intentional
   write and loses to the other side's explicit change.

Closes #10909

[zachmu]

Thanks for the contribution, @tanyongzhi . Sorry for the delay getting back to you, we didn't have a good process for monitoring outside PR submissions.

Take a minute and 1) merge from the tip of main, and 2) fix the failing bats tests. When you have, please ping @fulghum who can do a review for you to get this merged in.