go 1.18: prepare for next Go release

[gbotrel]

We did advertise in the past support for last 2 major Go releases, but some go 1.18 features may significantly change the codebase (in a good way) and warrant breaking this for a future release.

To explore / needs decision:

go 1.17:

• use reflect.VisibleFields and IsExported to simplify internal/...parser.go

go 1.18 (~ beta Dec 2021, release Feb 2022):

• generics are coming. Impact on gnark could be important: backend package is pointing to internal/... packages code generated with curve typed fr.Element, for each backend.ID. If we can instantiate constraint systems and backend objects typed with curves, without loss of performance, that would greatly simplify the codebase. No more code generation (or very little), possibility to expose directly the gnark objects (simpler serialization / deserialization workflows), etc. Need to experiment, here mentions interface{} are faster than generic in some cases...

• support for fuzzing . Lesser priority, but particularly in gnark-crypto, repacling gopter tests with a standard (as in long term / maintained) approach would make sense. Providing a wrapper (similar to test/Assert) to help circuit developers to fuzz witnesses for their circuit may be of separate interest.

• GOAMD64=v3 (see this). Some field arithmetic operations are implemented in assembly in gnark-crypto. I think we should only support =v3 arch through build tags, and fall back to generic for other (+ arm64 assembly). The core reason for using assembly is the use of v3 instructions (ADX, MULX, ..).