large-files: make sure we write newly initialized standin file early Any changing context will have to initialized it before anything else. Not flushing the default (pre-change) content mean we would enter the changing context with a dirty dirstate, which is odd.

dirstate: mark `clear` and `rebuild` as `require_changing_parents` Yeah, more scoping!

dirstate: add a comment about the semantic of `dirstate.clear` This method is weird, lets flag it as such.

debugrebuildstate: wrap the operation in a `changing_parents` context This ismaybe a "changing_files" case? However this would be the only usage of `rebuild` outside a `changing_parents` context and this is a debug command, so lets not make the code base more complex because of that one command.

strip: use a `changing_parents` context for --keep update These are now properly scoped. note: it would be neat to reuse this in `hg rollback`.

mq: wrap the dirstate's rebuild in a `changing_parents` context This code is dealing with `qreshesh` failure. In that case the working copy will be left on the parent of the refreshed patch, so the parents are changing and `changing_parents` make sens.

lfconvert: use a `changing_parents` context to clear the dirstate Not sure if this is the right context, but it works and it is consistent with the other usages of `dirstate.clear`.

dirstate: mark the `copy` method as requiring a `changing_any` context This is used both when changing parents (e.g. merging with rename) and changing files (e.g. running `hg rename`).

dirstate: add a `require_changing_any` decorator We will need it for a couple of usecase (e.g `dirstate.copy`).

rebase: scope parent change into a changing_parents context If we are actually altering the working copy (i.e. we are not in memory), we should properly scope the working copy update.