CMT: Subtree Append

[samwise2]

This PR adds functionality to append a subtree to a CMT!

The high-level process roughly goes as follows (similar to what @jarry-xiao initially outlined):

• Check that we are NOT trying to initialize the tree with an append (see below)
• Check that the subtree proof is valid for the subtree root
• Compute the new root of the tree by hashing the right most subtree leaf with other nodes in its rightmost proof, and then with the critical node (in the larger tree), and then with other nodes in the rightmost tree's RMP.
• Writeback the new changelog corresponding to the RML in the subtree
• Update the RMP index by incrementing it by the subtree's rightmost index

Why we only need one changelog in order to accurately fast-forward proofs for subsequent replace_leaf calls.

Why we don't allow initializing a CMT via subtree append (for now, worth for the future?):

[jarry-xiao]

I think the logic here is looking sound after your explainer comment. The main thing that still seems somewhat uncertain to me is how to actually go about performing a tree migration. Operationally, it seems difficult to "wait" for the desired indices to become available for append. Maybe this can be handled purely from the controlling contract level where aggregated trees completely ban regular appends and only allow for subtrees of a certain size to be appended. Still, this is definitely a step in the right direction