[BLS24] Fp24 tower

[yelhousni]

[ready to merge]

Currently, Fp24 is implemented as a tower Fp->Fp2->Fp4->Fp8->Fp24. The initial choice of this was to allow XTR-based compression of GT elements (which we haven't implemented yet). On the application side, we don't need the compression now, but maybe we would if we decide to implement Inner Pairing Product Argument (IPPA). This PR experiment with another choice of tower Fp->Fp2->Fp4->Fp12->Fp24. On the one hand, this has the advantage of faster inversion and conjugation as Fp24 would be a quadratic extension field. On the other hand, the q^4-th power Frobenius (FrobeniusQuad()) is slower as we don't use Fp8 elements anymore (on which FrobeniusQuad() acts as Conjugate()). The overall speedup in pairing is negligible as these operations are not very significant. However, as we are trying to speedup inverses in Fp (#80), it might be interesting to switch to this tower.

Bench:

benchmark                         old tower ns/op     new tower ns/op     delta
BenchmarkE24Add-2                 110           107           -2.73%
BenchmarkE24Sub-2                 103           101           -1.94%
BenchmarkE24Mul-2                 6827          6759          -1.00%
BenchmarkE24Square-2              4730          4713          -0.36%
BenchmarkE24Inverse-2             16465         14751         -10.41%
BenchmarkE24Expt-2                103156        102664        -0.48%
BenchmarkE24Conjugate-2           76.2          38.8          -49.08%
BenchmarkE24Frobenius-2           641           641           +0.00%
BenchmarkE24FrobeniusSquare-2     600           604           +0.67%
BenchmarkE24FrobeniusQuad-2       504           569           +12.90%

[gbotrel]

@yelhousni you need that one for this: Consensys/gnark#185 right?

I did not merge it since it starts with
"[to discuss]
do not merge yet"

[yelhousni]

@yelhousni you need that one for this: ConsenSys/gnark#185 right?

Yes. Actually, ConsenSys/gnark#185 uses the other tower option (the one already merged to develop) but we are likely to merge this PR #83 as it results in fewer constraints in gnark (for inverse and full-sparse mul). I still have few tests to do in gnark.