chore: Add hash_to_field Noir alternative

[kevaundray]

Description

Related to noir-lang/acvm#358

This only adds a test to show that we can implement the hash_to_field blackbox function in Noir.

Since hash_to_field takes Field elements as parameters, the decomposition shown is needed to hash a ~254 bit element instead of a single u8.

Problem*

Resolves

Summary*

Additional Context

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [Exceptional Case] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[github-actions]

Changes to circuit sizes

Generated at commit: 284ed3304027a3a216b5231bcec512c08dca3549, compared to commit: 4e2d35f256bea2fee3a6cbd7af0c0c15a37c0a2e

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
hash_to_field	+228 ❌	+22800.00%	+2,016 ❌	+10.38%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
hash_to_field	229 (+228)	+22800.00%	21,444 (+2,016)	+10.38%

[kevaundray]

I think a 10% slowdown is okay in exchange for one less ACIR opcode and we can optimize bytes32_to_field in the future by finding out the diff between the Noir algorithm and the bb algorithm.

EDIT: My mistake, the benchmark is 10% more because we modified the tests

[TomAFrench]

I think a 10% slowdown is okay in exchange for one less ACIR opcode and we can optimize bytes32_to_field in the future by finding out the diff between the Noir algorithm and the bb algorithm.

Most likely due to it using a slice for the byte decomposition. This adds a bunch of costs when it comes to turning it back into a [u8; 32]