`internal/field` is imported in `element_test.go`

[gbotrel]

    Because of this, generated files can not be embedded in another project as a standalone library.

Originally posted by @omerfirmak in #204 (comment)

[gbotrel]

@Tabaie :
element_test.go imports:

"github.com/consensys/gnark-crypto/internal/field"

I'm thinking, the need of common packages between field elements; forces projects that use gnark-crypto to actually have a dependency on gnark-crypto; (i.e; generating standalone code is more complex).
This is probably a healthier dependency management since these projects benefit from bug fixes, etc.

Let's deal with this (tests that depends on: "github.com/consensys/gnark-crypto/internal/field") , your latest PR #271 (ExpandMsg in hashutils ) and #218 together.

[gbotrel]

That being said; having standalone code generation for field that are not generated by gnark-crypto, well, depending on a version of hashutils for example, means that we force the library user to generate the code in their dev workflow (for the code generator to match the dependencies of the gnark-crypto/xxx imported packages)

[Tabaie]

So it's "healthy dependency management" vs "more complex workflow".
Is it actually the case that many of our users are only interested in field arithmetic? Even if so, my vote is that the pro outweighs the con.