chore: makes ec addition opcode unsafe

[guipublic]

This PR is the same as #8374, but with some added runtime checks as suggested by @zac-williamson. #8374 was merged and then rollback because it caused issues with e2e tests. We should not merge this one until this issue is fixed, but I need the PR as ready for review in order to have the CI to run.

The PR makes the ACIR opcode 'EC ADD' unsafe because the safety checks are now done on the Noir side in the stdlib's embedded curve operations. It will allow Aztec protocol circuit to use directly the opcode when the 'safety' is already known (and implied by previous operations).

EDIT: this unsafe EC ADD now handles points at infinity. If they are constant, it works as expected If not, it simply returns the infinity point. This ensures that there is no performance impact (the checks are constant-time), but still support in a way the infinite points, i.e it does not crash and returns a valid point, although it is an incorrect result, when the infinite status cannot be resolved at constant time.

[github-actions[bot]]

Changes to circuit sizes

Generated at commit: 393fe779227f5114dd6044e3b1c5dda768b6f719, compared to commit: 1801f5b49fb3b153817a1596c6fd568f1c762fe5

🧾 Summary (100% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
private_kernel_reset_4_4_4_4_4_4_4_4_1	0 ➖	0.00%	-4 ✅	-0.01%
private_kernel_reset	0 ➖	0.00%	-64 ✅	-0.01%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
private_kernel_reset_4_4_4_4_4_4_4_4_1	34,897 (0)	0.00%	74,475 (-4)	-0.01%
private_kernel_reset	91,933 (0)	0.00%	467,666 (-64)	-0.01%