Reduce zero-padding and cache zero-hashes in MerkleTree

[ljedrz]

This PR is the "plain" Merkle tree counterpart to https://github.com/AleoHQ/snarkVM/pull/2407.

While some of the console/collections/merkle_tree benchmark results are mixed, any regressions are small; however, I also ran a custom benchmark locally, and that one shows a clear improvement in extreme scenarios:

creation of a BHP MerkleTree with DEPTH = 23 and 2^22 + 1 random leaves

before:

alloc count: 38,230,906
heap use:    1.59 GiB
max heap:    2.10 GiB
time:        51.88s

after:

alloc count: 31,932,664 (-16.5%)
heap use:    1.47 GiB (-7.5%)
max heap:    2.00 GiB (-4.8%)
time:        42.61s (-17.9%)

[howardwu]

@vicsn @mdelle1 can each of you independently review this design change for correctness/completeness and soundness?

[ljedrz]

Note: I recommend that we finish https://github.com/AleoHQ/snarkVM/pull/2407, as some of the review comments there are applicable to this PR too.

[ljedrz]

Converting to a draft until https://github.com/AleoHQ/snarkVM/pull/2407 is reviewed, as they have many common features, and there are already review comments in that one that I've locally applied to this PR.

[vicsn]

Apart from one nit (adding the ensure), LGTM. This comment applies here too.

I was also told equivalence tests have been run on the binary merkle tree just like they were for the k-ary.

[ljedrz]

@vicsn PR updated; let me know if you agree with the second change, as it would also apply to the k-ary Merkle tree PR 😁. Also, the equivalence tests still pass.