Move more code from specifying fields via an integer `q` by instead giving a field

[fingolfin]

Right now a lot of functions take a field size q as argument, either as an alternative to specifying GF(q), or even as the only way to specify the field.

This is fine and well as long as there is a single unique such field. This is currently true in GAP for fields that are "small enough", but not in general.

With @frankluebeck's StandardFF package, we now have an alternative hierarchy of finite fields that work without Conway polynomials and hence are able to cover many more cases.

It would be quite nice if we could actually use these fields in many places. To this end, I think all functions that currently allow specifying a field size as an integer q should also allow passing a field object. Secondly, we should try to avoid using the q variant at least inside the library, and pass on field instead as much as possible. I guess that also means that Z(q) should be avoided in lieu of PrimitiveRoot(F) or PrimitiveElement(F) ?

Thoughts, @hulpke @ThomasBreuer @frankluebeck ?

[ThomasBreuer]

Yes, this was also my idea: Use the finite field itself as an argument instead of its size, and do not call Z in functions which get a finite field as an argument.

In practice, this means to change the code of existing methods which take a field size q such that the field itself is taken, and to add a new default method that takes q and calls the same operation with q replaced by GF(q).

There are already situations where both a field and a field size are allowed as inputs, and where the variant with a field delegates to the variant with the field size. These delegations have to be reversed. For example, GeneralOrthogonalGroupCons admits a field as an argument but delegates to the variant where the size of the field is entered. This affects also the methods installed in the Forms package.

Another aspect of admitting new implementations of finite fields is to adjust code for elements of finite fields. We have to distinguish IsFFE from IsStandardFiniteFieldElement (see issue #5055), in particular the GAP Reference Manual must point out that IsFFE means only those finite field elements that rely on Conway polynomials; note that these are the internal FFEs as well as non-internal FFEs such as ZmodpZObj( 1, 1073741827 ).

[hulpke]

I don't see a problem with this. We just need to be careful if code is inconsistent in passing q or GF(q) so that we do not end up with mixed representations.