dirstate: add a context for tracking files change Let us start to use it. We will enforce it later.

dirstate: invalidate the dirstate change on transaction failure If the change context lives inside a transaction, the change are not flushed to disk on exit as this is delegated to the transaction. As a result we should also delegate the part that do cleanup on failure. The issue was caught by tests with other change, but it seems useful to fix this as soon as possible.

dirstate: factor the "changing" context logic out This makes it reusable for other types of changes.

dirstate: introduce a `is_changing_any` property This will embrace other cases than changing parents.

dirstate: rename `pendingparentchange` to `is_changing_parents` This is clearer and more inline witht he other change we did.

dirstate: rename _parentwriters to _changing_level We will have context for changing more than parents, so lets be prepared.

largefiles: remove the `changing_parents` context in `openlfdirstate` This code might run in any kind of change context, we should rely on the higher level context instead of opening our own.

largefiles: remove the second `changing_parents` in `updatelfiles` Now that the `update_file` call have been migrated, we can drop the semantically-wrong `changing_parents` context.

largefiles: remove the first `changing_parents` in `updatelfiles` Now that the `update_file` call have been migrated, we can drop the semantically-wrong `changing_parents` context.

largefiles: use `hacky_extension_update_file` in `updatelfiles` This is what the function is meant for.

largefiles: use `hacky_extension_update_file` in `synclfdirstate` This is what the function is meant for.

largefiles: use `hacky_extension_update_file` in `openlfdirstate` This is what the function is meant for.

win32text: make the hacky call cover more cases Now that I understand what this is doing, It seems like the case for `p1_tracked` were covered by neither the code nor the test. Now the code cover it at least.

win32text: drop the `changing_parents` context in revert upgrade We are not changing parents here, so let us not pretend we do.

win32text: clean up and clarify the post-revert hack of dirstate The change is unrelated to changing parents and should not be a in a "changing_parents" context. This call is quite hacky, but now it is at least explicitly hacky. We will drop the `changing_parents` context in the next changesets, but we kept this change simple to help readability.