Revisit Model commit (sparql update) handling

[dlamoris]

This is model update part of #150, goal is to simplify transaction/race conditions handling and fully support multiple operations in a sparql update (except graph specific updates)

Proposed flow:

1. 'lock' the branch in the triplestore - there's already a transaction object that gets added, can further use that:

insert {
	transaction on branch
} where {
	not exist {
		other transaction on branch
	}
}

in addition can do auth etc check here
2. wrap the rest in a try catch to delete the transaction if any exception occurs
3. transaction added check, select staging graph, if txn doesn't exist return 409 (this can be similar to the check done by model query)
4. process user update - maintain update string

for each operation in the update:
	- exception if user specified graph, or unsupported operation
	- insert data, delete data, delete where - surround block with staging graph (WITH can't be used here?)
	- insert delete where - add WITH staging graph at the beginning
 - at the end add one more operation that inserts some transaction annotation that user update succeeded, can also do commit/branch metadata update here

• this would support any number of operations in one update, don't have to worry about variable clashing in trying to combine them
• should still be compatible with the commit patch string using ?__mms_model substitution in the update string for staging graph, minus the transaction/metadata operation

5. Query to check update succeeded, otherwise failed
6. remove transaction and return commit
7. do the stuff after an update (copy and make model graph)

Using the triplestore for the 'lock' have some risks if the server somehow crashed without cleaning up a transaction (would require a manual cleanup), but this would still work if layer1 is clustered.
Alternative is some kind of mutex in the code but would need to be a mutex per branch, would not work in a clustered deployment without some further considerations