Possibility for DOLT_MERGE to be less strict around stomping checks

In the following scenario:

1. Create branches X and Y.
2. Switch to branch X.
3. Add a new row to table `foo`.
4. Commit.
5. Switch to branch Y.
6. Add a new row to table `foo`.
7. Try to merge branch X into Y.

... the following error is thrown:

```
error: local changes would be stomped by merge:\n\tthing\n Please commit your changes before you merge.
```

I was wondering if this is a bug or intentional, since the two changes also seem compatible (?): whilst they do affect the same table, the incoming commit has added a new row to the table, which doesn't pose a problem for the other new row added in the working changes on Y. The current behaviour surprised me since with the new workspace tables, staging and committing can happen fine-grained per-row, but merging seems to be limited to a per-table check.

## Example SQL

```sql
CALL dolt_branch('TEST-COMMON', '--force');
CALL DOLT_CHECKOUT('TEST-COMMON');

CREATE TABLE thing (
id VARCHAR(36) PRIMARY KEY
);

CALL DOLT_ADD('thing');
CALL dolt_commit('--all', '--message', 'Add example schema', '--author', 'Test ');

CALL dolt_branch('TEST-X', '--force');
CALL dolt_branch('TEST-Y', '--force');

CALL DOLT_CHECKOUT('TEST-X');

INSERT INTO thing VALUES ('airblock-x');
CALL dolt_commit('--all', '--message', 'Example', '--author', 'Test ');

CALL DOLT_CHECKOUT('TEST-Y');
INSERT INTO thing VALUES ('airblock-y');

CALL DOLT_MERGE('TEST-X');
```

Start with the SQL reproduction using DOLT_CHECKOUT and DOLT_MERGE described in the issue, focusing on the local-changes stomp check for the `thing` table. Determine whether independent row additions can merge safely despite table-level changes, and add coverage showing the expected behavior before updating the merge logic.

Written by the indexing model from the issue text.