bls12381: Add map_to_g2 implementation

[wwared]

This PR adds a map_to_g2 function following RFC 9380, with implementation heavily based on circom-pairing's bls12_381_hash_to_G2.

The following pieces are included:

• assert_subgroup_check() for both G1 and G2
• clear_cofactor() for G2
• assert_is_on_curve() for both G1 and G2
• phi() and psi()/psi2() endomorphisms for G1 and G2 respectively
• scalar_mul_by_seed_square() for G1 subgroup check
• opt_simple_swu2() and iso3_map() functions
• sgn0() function added to bellpepper-emulated
• map_to_g2() function for turning a pair of Fp2 elements into a G2 point

Any constants added were either taken directly from the RFC or from circom-pairing's source code.

This PR requires this additional commit to the bls12_381 fork exposing a few extra private crate members, mainly to support the new tests. The feature experimental is necessary to include the hash_to_g2 module. This PR also adds short docstrings for most useful g1 and g2 functions and some minor refactors.

Additional improvements and cleanup included in the PR:

• The default limb count/bit size has been set to 7/55 instead. This value seems to give the lowest amount of constraints for the emulated field operations when the base field is Bn256, which is what we actually care about. The performance in pasta's Fp isn't much worse so it seems like better defaults to use. (For the record: gnark uses 6/64, circom-pairing uses 7/55)
• The tests now run on Bn256 instead of pasta
• Unnecessary allocations and reductions were cleaned up and reorganized
• Addition of eager modular reductions in Fp12Element::square() that resulted in the majority of performance gains

The current constraint count for one pairing is now 7.1M constraints (down from >20M), and two pairings take 17M constraints. A map_to_g2() call takes 1.4M constraints. :tada: (However, the pairing tests remain commented out because they take over 60 seconds to run, and the multi_pairing test requires too much RAM, so CI fails trying to run them)

Future work in upcoming PRs:

• Implement the hash_to_curve section of RFC 9380
• A better add_or_double implementation based on gnark's AddUnified
• Properly document and add workarounds for when a point at infinity is passed to the important top-level functions. Currently, most functions (pairing(), map_to_g2()) will simply fail due to a division by zero, but these edge cases should be properly documented and tested (and fixed if they should not fail)

[huitseeker]

@wwared I have pushed a rebased version of this branch to https://github.com/lurk-lab/bellpepper-gadgets/tree/blshashtog2_rebased, which I believe is just a plain vanilla rebase of this PR. I will stamp this PR the minute it's reset to that branch (or something better, in case I have made a mistake).

@wwared please also link with @samuelburnham to make sure you have the ability to merge your own PRs on this repo, you should absolutely not be blocked on somebody merging your (approved) PRs in any circumstance.

[wwared]

@wwared I have pushed a rebased version of this branch to https://github.com/lurk-lab/bellpepper-gadgets/tree/blshashtog2_rebased, which I believe is just a plain vanilla rebase of this PR. I will stamp this PR the minute it's reset to that branch (or something better, in case I have made a mistake).

I'm finishing rebasing the branch right now, running the tests to ensure I didn't screw anything up and double checking that I didn't reintroduce anything, will force push once everything is green.

@wwared please also link with @samuelburnham to make sure you have the ability to merge your own PRs on this repo, you should absolutely not be blocked on somebody merging your PRs in any circumstance.

Will do!

[huitseeker]

@wwared You're good to merge!