Specification algorithms could benefit from note on atomicity

[apasel422]

Since the API's state is mutable from multiple contexts simultaneously, we may want to note that certain operations must be atomic for correctness (including upholding the privacy model).

For example, two contexts may attempt to deduct privacy budget for the same (epoch, topLevelSite) simultaneously, and therefore trample one another's execution of:

1. If the privacy budget store does not contain key, set its value of key to be a user agent-defined value, plus 1000.

I'm not sure what precedent there is in other specifications for noting this kind of requirement, but I think it would be beneficial for us to note that the save impression algorithm effectively takes a lock on the impression store, while measure conversion takes a lock on the impression store, privacy budget store, epoch start store, and last browsing history clear, and that in all cases, writes to this state must be performed atomically.

[martinthomson]

We should audit the spec to ensure that we don't access state from two places in parallel. One way to do that is being consistent about the choice of task source to dispatch things to. We might want to say that certain stores are bound to a particular task source.

[martinthomson]

We should also check for early returns that might change the transactional nature of certain actions.