Deleting from `dolt_conflicts_` can cause a panic when there's a schema change.

[nicktobey]

Repro steps: from a clean repo, run the following:

@@dolt_allow_commit_conflicts = 1;
call dolt_checkout('-b', 'old');
create table test(a int primary key, b int, c int);
call dolt_add('test');
call dolt_commit('-m', 'create test table');

call dolt_checkout('-b', 'new');
alter table test drop column c;
insert into test values (1, 5);
call dolt_add('test');
call dolt_commit('-m', 'insert into 2-col table');

call dolt_checkout('old');
insert into test values (1, 2, 3);
call dolt_add('test');
call dolt_commit('-m', 'insert into 3-col table');

call dolt_merge('new');
delete from dolt_conflicts_test;

Expected behavior: conflicts are resolved in favor of the local values. Actual behavior:

panic: impossible conversion

goroutine 291 [running]:
github.com/dolthub/dolt/go/libraries/doltcore/sqle/index.convInt(...)
	github.com/dolthub/dolt/go/libraries/doltcore/sqle/index/prolly_fields.go:296
github.com/dolthub/dolt/go/libraries/doltcore/sqle/index.PutField({0x300ea90?, 0xc004791540?}, {0x3015c38?, 0xc000832280?}, 0x4?, 0x1e?, {0x267e280?, 0xc002d30830?})
	github.com/dolthub/dolt/go/libraries/doltcore/sqle/index/prolly_fields.go:181 +0x1b25
github.com/dolthub/dolt/go/libraries/doltcore/sqle/dtables.(*prollyConflictDeleter).putPrimaryKeys(0xc00069d080, 0xc004f72480?, {0xc0065a0d20, 0x1e, 0x1a43ed210475ee70?})
	github.com/dolthub/dolt/go/libraries/doltcore/sqle/dtables/conflicts_tables_prolly.go:620 +0x248
github.com/dolthub/dolt/go/libraries/doltcore/sqle/dtables.(*prollyConflictDeleter).Delete(0xc00069d080, 0xc004791540?, {0xc0065a0d20, 0x1e, 0x1e})
	github.com/dolthub/dolt/go/libraries/doltcore/sqle/dtables/conflicts_tables_prolly.go:581 +0xc5
github.com/dolthub/go-mysql-server/sql/rowexec.(*deleteIter).Next(0xc000c9a370, 0xc004791540)
	github.com/dolthub/[email protected]/sql/rowexec/delete.go:95 +0x17c
github.com/dolthub/go-mysql-server/sql/plan.(*TableEditorIter).Next(0xc000c9a3c0, 0xc004791540)
	github.com/dolthub/[email protected]/sql/plan/table_editor.go:55 +0x72
github.com/dolthub/go-mysql-server/sql/rowexec.(*accumulatorIter).Next(0xc000cc6870, 0xc004791540)
	github.com/dolthub/[email protected]/sql/rowexec/dml_iters.go:513 +0x1f6
github.com/dolthub/go-mysql-server/sql/rowexec.transactionCommittingIter.Next(...)
	github.com/dolthub/[email protected]/sql/rowexec/transaction_iters.go:78
github.com/dolthub/go-mysql-server/sql/plan.(*trackedRowIter).Next(0xc000c4ab80, 0xc00097aeb0?)
	github.com/dolthub/[email protected]/sql/plan/process.go:347 +0x24
github.com/dolthub/go-mysql-server/server.(*Handler).doQuery.func2()
	github.com/dolthub/[email protected]/server/handler.go:286 +0x125
golang.org/x/sync/errgroup.(*Group).Go.func1()
	golang.org/x/[email protected]/errgroup/errgroup.go:75 +0x56
created by golang.org/x/sync/errgroup.(*Group).Go in goroutine 223
	golang.org/x/[email protected]/errgroup/errgroup.go:72 +0x96

The issue is caused by the fact that the merge contains a schema change: in this case, the branch being merged in has dropped a column. The code for resolving conflicts when rows are deleted from dolt_conflicts_$ was written before we supported merging schema changes, and is likely indexing into the merged schema incorrectly and getting the wrong type for a column.

Workaround: Use the CALL DOLT_CONFLICTS_RESOLVE('--ours', <table>); stored procedure instead.

What can't be worked around: Resolving conflicts by setting values in dolt_conflicts_$ also causes a panic, and there's no simple alternative.