Crypto crate imporvmements

This note describes potential improvements for the miden-crypto crate. The improvements can be broken down into 3 groups:

API improvements and minor optimizations

The purposes of these improvements is to make the APIs of the crate more intuitive and also to implement "low-hanging-fruit" performance optimizations. The changes include:

• Improvements to the MMR data structure APIs, including #196, #262, #299.
• Normalizing APIs across various Merkle data structures (e.g., using open() consistently for generating Merkle proofs).
• Implementing compact Mekrle path data structure (i.e., #215).
• Improvements to the SMT APIs (e.g., #271, #272).

Merkle structs performance optimizations

The purpose of these imporvements is to speed up various aspects of our existing Merkle data structures. Specifically:

• Staged updates to minimize the time a given data structure needs to be locked for to perform a bulk update. This is primarily relevant to the Smt data structure but may also be useful for regular Merkle trees and MRR. There is discussion of how this can be achieved in #222.
• Multi-threaded construction of Sparse Merkle trees and potentially multi-threaded bulk updates (see #300 for discussion, though this would apply more broadly).

Large capacity Sparse Merkle trees

Currently, our Sparse Merkle tree implementation (i.e., the Smt struct) has a purely in-memory representation. This will work fine when the amount of data stored in the tree is dozens of GB, but will break down when we'll need to store hundreds of GB in an Smt (as we may need for the nullifier tree in the Miden rollup). The purpose of these improvements would be to develop an approach which implements a variant of our Smt struct which can efficiently accommodate up to several terabytes of data inserted into it.

One of the metrics we are interested in optimizing here is performing as few disk reads/writes as possible when looking up values or updating values in an Smt.