Fix FieldOfMatrixGroup for certain classical matrix groups in dimension up to 2, and fix related problems with their invariant forms

[ThomasBreuer]

• add a component baseDomain to the records that describe invariant forms; note that the field automorphism for sesquilinear forms can in general not be deduced from the matrix group and the matrix of the form (the problematic cases are unitary groups in dimension 2) and the field of definition can be different from (larger than) the field of the matrix entries for some orthogonal groups in dimension 1, see the code lines where FieldOfMatrixGroup gets set,
• correct or verify the SetFieldOfMatrixGroup calls that occur, and add comments,
• adjust and extend the tests for groups that store invariant forms,
• fix the \in and NrConjugacyClasses methods that are based on an invariant sesquilinear form, the field automorphism must be derived from the baseDomain of the form, not from the FieldOfMatrixGroup of the group,
• adjust the documentation of InvariantBilinearForm, IsFullSubgroupGLorSLRespectingBilinearForm, InvariantSesquilinearForm, IsFullSubgroupGLorSLRespectingSesquilinearForm, InvariantQuadraticForm, IsFullSubgroupGLorSLRespectingQuadraticForm,
• support also sesquilinear forms in the recently added ConjugateGroup method for matrix groups (one could transfer the form in more situations, but perhaps it is anyhow a bad idea to allow a too general setup)

[lgoettgens]

I think it would make sense to add a check that F does not contain more than 1 element, to not just silently discard some input

[ThomasBreuer]

O.k.

[fingolfin]

Why not just make it take 3 arguments?

Suggested change

	BindGlobal( "SetInvariantQuadraticFormFromMatrix", function( g, mat, F... )
	if Length( F ) <> 1 then
	# In earlier versions of GAP, no 'baseDomain' was stored.
	Error( "only the three argument variant of ",
	"SetInvariantQuadraticFormFromMatrix is supported" );
	fi;
	SetInvariantQuadraticForm( g, rec( matrix:= mat, baseDomain:= F[1] ) );
	SetInvariantBilinearForm( g, rec( matrix:= mat+TransposedMat(mat),
	baseDomain:= F[1] ) );
	BindGlobal( "SetInvariantQuadraticFormFromMatrix", function( g, mat, F )
	SetInvariantQuadraticForm( g, rec( matrix:= mat, baseDomain:= F ) );
	SetInvariantBilinearForm( g, rec( matrix:= mat+TransposedMat(mat),
	baseDomain:= F ) );

[ThomasBreuer]

When functionality disappears in a new version, I find it helpful to get a hint for the reason, in this situation an error message that can be identified in the code. I thought an unspecific error would be unfriendly.
(In fact, I do not expect that anybody has used the function in question in private code.)

[fingolfin]

For whom is this comment intended, and what should they learn from it exactly?

To me, it is rather puzzling. Why is it necessary to justify the use of FieldOfMatrixGroup over baseDomain? Conversely, if there is a need to justify this, then why not just use baseDomain, that way nothing has to be justified? (Maybe?)

[ThomasBreuer]

First of all, I made this comment for myself.

Logically, all uses of FieldOfMatrixGroup in the context of forms should be replaced by uses of the stored baseDomain.

For the membership test, however, the result is the same in both cases, and the FieldOfMatrixGroup can be smaller than the baseDomain. For a matrix mat that is defined over the baseDomain but not over the FieldOfMatrixGroup, using FieldOfMatrixGroup in the test yields a false result without checking whether the form is respected, whereas testing for baseDomain requires the check of the form. Thus FieldOfMatrixGroup behaves better in this situation.