When performing complex edits, pause sub-editors before they publish to propagate "Must Encrypt" and other state

Summary:
See PHI1134. Previously, see T13082 and D19969 for some sort-of-related stuff.

Currently, edits work roughly like this:

• Suppose we're editing object X, and we're also going to edit some other object, Y, because X mentioned Y or the edit is making X a child or parent of Y, or unblocking Y.
• Do the actual edit to X, including inverse edits ("alice mentioned Y on X.", "alice added a child revision: X", etc) which apply to Y.
• Run Herald rules on X.
• Publish the edit to X.

The "inverse edits" currently do this whole process inline, in a sub-editor. So the flow expands like this:

• Begin editing X.
• Update properties on X.
  • Begin inverse-edge editing Y.
  • Update properties on Y.
  • Run (actually, skip) Herald rules on Y.
  • Publish edits to Y.
• Run Herald rules on X.
• Publish edits to X.

Notably, the "Y" stuff publishes before the "X" Herald rules run. This creates potential problems:

• Herald rules may change the name or visibility policy of "X", but we'll publish mail about it via the edits to Y before those edits apply. This is a problem only in theory, we don't ship any upstream rules like this today.
• Herald rules may "Require Secure Mail", but we won't know that at the time we're building mail about the indirect change to "Y". This is a problem in practice.

Instead, switch to this new flow, where we stop the sub-editors before they publish, then publish everything at the very end once all the edits are complete:

• Begin editing X.
• Update properties on X.
  • Begin inverse-edge editing Y.
  • Update properties on Y.
  • Skip Herald on Y.
• Run Herald rules on X.
• Publish X.
  • Publish all child-editors of X.
    • Publish Y.

Test Plan:

• Created "Must Encrypt" Herald rules for Tasks and Revisions.
• Edited object "A", an object which the rules applied to directly, and set object "B" (a different object which the rules did not hit) as its parent/child and/or unblocked it.
• In bin/mail list-outbound, saw:
  • Mail about object "A" all flagged as "Must Encrypt".
  • Normal mail from object B not flagged "Must Encrypt".
  • Mail from object B about changing relationships to object A flagged as "Must Encrypt".

Reviewers: amckinley

Reviewed By: amckinley

Differential Revision: https://secure.phabricator.com/D20283