feat: implement multiproof generation

[estensen]

Resolves #123
An alternative implementation to #157 to only build the tree once when generating multi proofs.

Would it be more ergonomic to change the API and decoupling tree building from proof generation to make implementation more modular and easier to benchmark? The way the code is currently structured if you wanna create a proof and then a multiproof you need to build the tree twice. Alternatively the tree itself could be cached.

Merkleproofs had no tests, so I added some basic ones to make sure I don't break it too bad while optimizing.

Most of the time is spent on building the tree, not generating the proofs themselves, so stacking #169 and #170 should get down to less than 30ms:

MultiProve Benchmark - File: benches/21315748.json - size 247/Generate Single Proof
                        time:   [446.69 ms 447.43 ms 448.28 ms]
MultiProve Benchmark - File: benches/21315748.json - size 247/Verify Single Proof
                        time:   [6.8539 µs 6.8755 µs 6.8968 µs]

MultiProve Benchmark - File: benches/21315748.json - size 247/Generate Ten Proofs
                        time:   [453.34 ms 454.12 ms 455.01 ms]
MultiProve Benchmark - File: benches/21315748.json - size 247/Verify Ten Proofs
                        time:   [26.836 µs 27.267 µs 28.143 µs]

MultiProve Benchmark - File: benches/21327802.json - size 261/Generate Single Proof
                        time:   [459.21 ms 461.32 ms 464.11 ms]
MultiProve Benchmark - File: benches/21327802.json - size 261/Verify Single Proof
                        time:   [7.0034 µs 7.0473 µs 7.1087 µs]

MultiProve Benchmark - File: benches/21327802.json - size 261/Generate Ten Proofs
                        time:   [462.67 ms 465.52 ms 468.85 ms]
MultiProve Benchmark - File: benches/21327802.json - size 261/Verify Ten Proofs
                        time:   [27.273 µs 27.342 µs 27.452 µs]