Enforce uniqueness of primary key fields at import/commit time

[olsen232]

GPKG only supports integer primary keys, whereas a Kart dataset already supports string primary keys.
We should be able to adapt one to the other in some way so that you can have a GPKG working copy that is backed by a dataset with string keys - perhaps a dummy integer primary key will be added, and the original string primary key will present in the working copy but not in the primary key column.

[olsen232]

Done except there is one more edge case that hasn't been dealt with and could do with some more work:

• what happens if you drop a column in QGIS, which blows away any unique constraints, then start adding non-unique values in the string-pk column?

[craigds]

I'd suggest we add some code to check for dupe PKs at commit time, in the case that the WC isn't enforcing that for us. Throwing a useful error seems like it would adequately fix this problem, something like

mydatasetname: The value 'abc-123' in the "pk" column is not unique. Please fix this and try committing again.

[craigds]

to add to this, even if the WC or import source does normally enforce uniqueness of PKs, you can bypass that by doing kart import --primary-key customfield ..., and kart should check that field for uniqueness.