feat(stdlib): Implement elliptic curve primitives

[ax0]

Related issue(s)

Partially resolves #393

Description

This PR implements elliptic curve primitives over Field, specifically the group operations (addition, subtraction, scalar multiplication) and curve mappings required for hash_to_curve (Simplified SWU and Elligator 2 methods). The implementation includes Montgomery, Short Weierstraß and Twisted Edwards curve configurations, though the Montgomery curve implementation is minimal and included only for the purpose of curve mappings (i.e. the group operations are induced by those for the corresponding Twisted Edwards curve). All curves include both affine and 'CurveGroup' (i.e. projective or extended) coordinate representations. The structure and choice of terminology are loosely based on those of ark-ec. A more detailed description of the implementation is included in ec.nr.

Multi-scalar multiplication is implemented as well but does not work at the moment due to the lack of support for arrays of structs. Also, I was hoping to avoid code duplication e.g. in the definition of bit_mul (multiplication by a scalar represented by a bit array) for each curve configuration by using higher-order functions (cf. the commented-out definition of bit_mul in ec.nr), but I ran into the problem where I couldn't generate proofs.

Summary of changes

• Addition of elliptic curve configurations and operations in ec.nr and under ec/
• Addition of parity method in field.nr

Dependency additions / changes

Test additions / changes

One test case in nargo/tests/test_data/ec_baby_jubjub, which tests the library on the Baby Jubjub curve.

Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt with default settings.
• I have linked this PR to the issue(s) that it resolves.
• I have reviewed the changes on GitHub, line by line.
• I have ensured all changes are covered in the description.

Documentation needs

• This PR requires documentation updates when merged.

Additional context

[arielgabizon]

Shouldn't z be fixed to a constant satisfying the conditions here https://datatracker.ietf.org/doc/id/draft-irtf-cfrg-hash-to-curve-06.html#section-6.6.2
rather than a parameter?

[ax0]

It should indeed. At the time of this PR, it wasn't possible to compute the constant in Noir without adding unnecessary constraints, which is why I left it as a parameter here, unlike the case of the Elligator 2 method whose constant depends only on the field and not on the curve. Now that unconstrained functions are a thing, this should be easy to resolve.