large-files: use `running_status` in `scmutiladdremove` This is the way.

large-files: open the transaction sooner in `scmutiladdremove` We want it to encompass the status call.

large-files: use `running_status` in `overriderevert` This is the way

large-files: use `running_status` in `updatestandinsbymatch` This is the way.

large-files: wrap reposetup's status in a `running_status` context This is the way.

narrow: use `running_status` in `updateworkingcopy` This is the way.

status: use `running_status` in dirstate status This is the way.

status: pre-indent the dirstate status code This make the next changeset clearer.

dirstate: introduce a (noop) running_status context Let us start with a simplistic context so we can scope the appropriate code before adding more logic.

status: invalidate dirstate on LockError If we cannot take the lock, someone else is modifying the repository. Let us discard dirstate uncommitted data before exiting the status code. Having a clean dirstate after such operation seems safer. Strictly speaking, there is a small behavior change in the following situation: * process A call `status` outside of the `wlock` * process B grab the `wlock` * process A fails to acquires the lock to write status fixup * process B release the `wlock` *without touching the dirstate* * process A later grab the `wlock` * process A can write dirstate update from earlier `status` However this is a fairly hypothetical situation : * process A has to be raced * process B have to not update the dirstate * process A has to run another *unrelated* operation later. This seems rare enough to overlook. I am stating that the two operations in process A has to be unrelated. Otherwise, collecting status data outside of the lock to use them inside the lock is racy. Any other process could move things around (eg: the working copy) making the data collected during status irrelevantor even harmful. If such code exists, it should be fixed ASAP.