Find a deeper fix for postgres concurrency issues, re. multiple commands updating a map's/user's edit-count

[Venryx]

Debate-map should be more resilient to concurrent update commands. (which sometimes cause claimminer map generations to fail)

So for example:

• We could reduce the isolation level for the transactions, eg. from Serializable to Repeatable Read. (perhaps selectively, when just updating the user's edit-count?)
• Or we could change the way that "edit count" is stored, to reduce the chance/possibility of contention. (eg. postgres might have a native way to increment a number in a way that never has concurrency errors)
• Or (for this specific case) a fix would also be to not update that "edit count" value when claim-miner is doing it for a map generation.

[Venryx]

I've pushed the following change:

• MS the commands that increment edit-counts (of user and/or map) have a new field in their "input" structure called "incrementEdits", which allows for that edit-incrementing to be disabled.

Once claim-miner is updated to use the fields above (disabling edit-count incrementing during its import-related commands), this immediate problem should be fixed. (may still want to resolve it in a deeper way down the road)