Fix: Bandersnatch GLV scalar multiplication

[yelhousni]

Description

Fixes #268

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

How has this been tested?

TestCurve for Bandersnatch pass when using scalarMulGLV.

How has this been benchmarked?

Bandersnatch in R1CS:
2-bit windowed double-and-add: 3,314
GLV: 2,735
Bandersnatch in SCS:
2-bit windowed double-and-add: 5,991
GLV: 6,077

So the GLV saves 579 r1cs but adds 86 scs, which is because of the non-native scalar decomposition check. In this PR we use GLV only if endomorphism + R1CS.

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I did not modify files generated from templates
• golangci-lint does not output errors locally
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[gbotrel]

A remark, that probably applies to other neighbor pacakges;

I checked the call graph to see how it is tested, and it seems we just test with testData --> with random scalars.

Should we add some edge cases tests ? (i.e. scalar at 0, p-1, 1, ...),

[yelhousni]

A remark, that probably applies to other neighbor pacakges;

I checked the call graph to see how it is tested, and it seems we just test with testData --> with random scalars.

Should we add some edge cases tests ? (i.e. scalar at 0, p-1, 1, ...),

Yes indeed we should test edge cases. We already do so for emulated and native SW packages. Here it should be easier because formulas are complete.