Add explicit mechanism for preventing the submission of dangerous SharedTree commits

[noencke]

Description

Currently, if the application of a local commit crashes a SharedTree client, that client will crash before sending the op to other clients, which prevents them from crashing in turn. This is good, but the way that it is currently achieved is somewhat obfuscated, relies on bizarre event ordering guarantees, and is preventing some future features from being possible.

More specifically, the checkout currently updates its forest in response to its branch's "beforeChange" event. This is because op submission happens in response to the "afterChange" event, so if the checkout crashes during "beforeChange", we won't progress to "afterChange". However, that means that when the end user of SharedTree receives a "nodeChanged" or "treeChanged" event, it will be in the context of the "beforeChange" event - so the forest will be updated according to their change, but the commit graph will not. Therefore, they cannot (sanely) do operations that affect the commit graph - like forking or merging their branches - in an event handler. This PR moves the forest update to the "afterChange" event, so that the commit graph is updated before the user's event handler is called. It does this by adding an explicit mechanism to the checkout for monitoring when commits have been "validated" - and SharedTree then uses this to determine when they should be submitted to other clients. SharedTreeCore now attempts to submit commits during "beforeChange", not "afterChange", but is intercepted by SharedTree and then delayed until after validation.

This PR also does a smattering of other related cleanup, including:

• Removing the return values from all the branch operations, for simplicity.
• Adjusting the arguments to "beforeBatch" and "afterBatch" to suit their usage and adding documentation.
• Tightening the arguments to SharedTreeBranchChange and improving the documentation.
• Adding a helper function for implementing lazy+cached properties, and using it to optimize the merge operation of SharedTreeBranch as well as for a cached property in the rebase logic.
• Removing the current (and confusing) injection of the event emitter from the SharedTree into the checkout, and moving it into a more explicit load function. While still ugly, it is at least straightforward, and it combines with and cleans up the existing "on load" function setTipRevisionForLoadedData().

Copilot reviewed 5 out of 6 changed files in this pull request and generated no suggestions.

Files not reviewed (1)

• packages/dds/tree/src/shared-tree-core/index.ts: Evaluated as low risk

Comments skipped due to low confidence (1)

packages/dds/tree/src/shared-tree-core/sharedTreeCore.ts:311

• The 'isResubmit' parameter is now required in the 'submitCommit' method, but there might be places where this method is called without providing this parameter. Ensure all calls to this method provide the 'isResubmit' parameter.

isResubmit: boolean,