Changing an object's state in Space.modifyThing() isn't sufficiently atomic

Summary: There is a race condition, deep inside the Space code. It isn't huge, but there is probably a fair fraction of a second wherein, if we get two change requests for a given Thing, one of them may be lost.

The problem is during the window while the change request is out to the Persister. If another change comes in before the Persister completes, it can stomp the first change. This is definitely not acceptable.

Need to think through the entire lifecycle of a change request. This may require introducing the versioning system that we are going to use to provide collision detection at the UI level. But we definitely need to find an approach that lets us detect the change collision, and either merges the changes intelligently, or rejects the latter change and lets the UI deal with the fallout. The implication is that, when the first change comes in, we need to record that a change is in process before we send it off to the Persister, so that the collision can be detected.

LATER: a simpler and better solution is probably to simply do the entire change before sending it to the Persister. The critical tweak is that modTime needs to be generated by the Space, not by the Persister. I probably want to make that change for a host of other reasons anyway. So the workflow would become that we record the change in state, then send the reply to the caller, then send it to the Persister. This will considerably improve latency, as well. Ideally, if there is a Persistence error, we should feed that back to the user, but preferably we shouldn't have to wait on that. (Frankly, there are probably no Persistence errors that aren't fatal-grade anyway.)