fix: enforce correct length of hashConstructor args

[dbanks12]

Description

• Closes TS hashConstructor is not providing fixed length 8 array for args #320
• Blocks fix: use standard serialized vector of frs in function tree cbinds #314
• Blocks Fix Rollup Tests (for Local testing) #298
• Blocks Refactor Types (and use latest barretenberg) #305
• Short term fix in feat: zero leaf indexed tree #285

It was discovered that hashConstructor was sending any length array of args to the abis__hash_constructor cbind. That cbind always deserializes args into an array of length ARRAY_LENGTH since it expects a statically typed array. Our abis.test.ts was passing 2 args in and the C++ was serializing those 2 plus 6 garbage args into the array. So the output of hashConstructor was wrong and non-deterministic.

This PR fixes this by enforcing that the C++ cbind always gets an array of proper length.

Contents

• hashConstructor enforces that args.length() <= ARGS_LENGTH
• before calling the cbind, hashConstructor fills out args until full with new Fr(0)
• added a test for max args
• added test that expects throw on >max args
• updated snapshots which should now be stable
• some autoformatting changes that happened when doing a merge commit of phil's latest work

Checklist:

• I have reviewed my diff in github, line by line.
• Every change is related to the PR description.
• I have linked this pull request to the issue(s) that it resolves.
• There are no unexpected formatting changes, superfluous debug logs, or commented-out code.
• The branch has been merged or rebased against the head of its merge target.
• I'm happy for the PR to be merged at the reviewer's next convenience.

[dbanks12]

Thanks @suyash67 for pairing on this with me. @Cheethas looks like you and @LHerskind made a fix to the failing test in master while I was discovering this on my own.... Lmk what you think of my fix to hashConstructor and the new tests.

[spalladino]

This explains why that snapshot had unexpectedly changed at some point. Thanks @dbanks12 for fixing it!

[dbanks12]

This explains why that snapshot had unexpectedly changed at some point. Thanks @dbanks12 for fixing it!

My pleasure!