Integrate Merkle Tree implementation from Plonky3

[frozenspider]

Reworked Merkle Tree approach used in Zinc.

Instead of a makeshift implementation, rely on the one designed by https://github.com/Plonky3/Plonky3 - just like https://github.com/tcoratger/whir-p3 does.

This particular MT is designed to commit to matrices, each matrix row becoming an MT leaf that is opened together. This is very convenient for Zinc since we need to open entire columns. For that, we transpose a matrix before committing.

Most changes in this PR are trivial due to required implementation of Copy trait for Integer. Main changes are:

• Use Plonky3's MT implementation to commit to entire u-hat matrix
• There's now one MT root hash for a matrix, instead of a one per-row
• This also makes proof size much smaller due to only one Merkle proof being needed per opening
• Hash type has been wrapped in MtHash for ease of change
• Fixed an issue in verify_testing where the result of verify_column was silently ignored
• In addition, encode_rows and matrix transposal is made using MaybeUninit and a minimal amount of unsafe code, yielding ~10% speedup of a commit operation.

Benchmarked running time changes of zip_benches, single threaded:

• Zip/EncodeRows: (about the same)
• Zip/MerkleRoot: +25% (since we're no longer optimizing for committing to individual leaves)
• Zip/Commit: -58%
• Zip/Open: -50%
• Zip/Verify: -55%

Multi-threaded + asm:

• Zip/EncodeRows: (about the same)
• Zip/MerkleRoot: (about the same)
• Zip/Commit: -95%
• Zip/Open: -40%
• Zip/Verify: (fails both before and after, see Zip/Verify benchmark doesn't work with parallel feature flag on #141)

[github-actions]

Coverage (base → head): 75.87% → 75.74% ⬇️ 0.13 pp
Only posts when PR coverage is lower than the base branch's latest push (or freshly computed base).

[cupicmarko]

Looks good, I would just like to in depth through transcript, because there might be some mixing of endianness, so it's not going to be completely portable.

[frozenspider]

@cupicmarko Good catch! My AsBytes implementation was indeed endianness dependent. Reworked it to AsWords and use fixed endianness while still avoiding unnecessary allocations and materializations (by compiler's virtue).

[NiDimi]

Looks good, but there is a small typo