feat(stark): implement StatefulBlake3Hasher

This is somewhat intentional and a conscious design decision motivated by the alignment property we get with sponge-based constructions.

The chaining hasher was meant as an easy compatibility layer for existing CryptographicHashers, which unfortunately does have different semantics, though hopefully not too big of a performance impact.

We should be able to define an actually custom StatefulBlake3Hasher using the `hazmat` API. I think this would be good to investigate if we notice a performance difference between the LMCS and MMCS. The trade off for better performance would be memory footprint (256 byte state vs 32 digest size) and unsafe-ish code manually implementing the hash.

But to answer your question, these are indeed semantically different Merkle trees, but from the caller of the MMCS/LMCS they're functionally the same. As mentioned above, this benchmark is actually useful for comparing the different approaches to absorbing rows of multiple matrices.

---

Ported from https://github.com/0xMiden/p3-miden/issues/63

The issue discusses implementing a StatefulBlake3Hasher using the hazmat API for performance in Merkle tree constructions. Start by examining the existing CryptographicHasher implementations and the hazmat module. Look at the LMCS and MMCS code to understand the matrix absorption context. A successful implementation will need to manage a 256-byte state and integrate with the benchmark for comparison.

由索引模型根据 Issue 内容生成。