FLComponents refactoring to compute FLTranvservals

[nehaniv]

We need to separate computing the transversals from the component actions. If there are large index subgroups in the chain, then it may not be feasible to commute the component action directly but we might still be able to compute the right transversals and use this to coordinatize states, compute level killers, etc, using FLCoords2Reps, etc.

How to solve: (by simple code refactoring)

1. FLComponents takes a subgroup chain and returns component actions and transversals, computing both going down a subgroup chain.

2. Instead, FLComponents should call a new function FLTransversals to get all the transversals first. Then it should should use these to component the component actions.
   FLTranversals (subgroupchain)

(This came up today trying to work with the Impossiball puzzle.)

I will implement and make a pull request.

[nehaniv]

Did refactoring on branch. Put example output in dev/fl-new.tst for integration into fl.tst. Requested pull.

[nehaniv]

Thanks for merging. I think there may be other similar changes needed to improve feasibility of decompositions and their consistency. E.g. FLTransversals should be allowed to take a FLCascadeGroup, and would then just return its transversals as stored in its rec rather than recomputing them (possibly with different results!). Also FLCoords2Reps and FLCoords2Perm should be allowed to take either transversals or an FLCascadeGroup (FLG) as an argument (in the latter case one uses the transversals already associated to the FLCascadeGroup). Similarly other functions that take transversals (e.g. Perm2Reps, should be allowed to take as 2nd argument either transversals (as they currently do), or a FLCascadeGroup (and read its transversals) if they are not in computationally intensive loops.

[nehaniv]

DisplayFLComponents. If this is called with a FLCascadeGroup, it's clear what to do, and is the current functionality. If it is called with a subgroup series, or with transversals, one could give a sensible response without trying to lift generators: namely the components are (Gi/G{i+1} = Size(transversal)) acted on by FactorGroup applied to Gi and Core of G{i+1} in G_i. This avoids having to act explicitly on binary encoded sets of cosets.

[egri-nagy]

DisplayFLComponents can do this since https://github.com/gap-packages/sgpdec/commit/fb3c8d86da449f4ea501fdb032072322ee7e2ea3

[egri-nagy]

For an FLCascadeGroup the underlying transversals are stored in TransversalsOf attribute, which is just the result of FLTransversals. Yes, the naming is not consistent.

[egri-nagy]

With https://github.com/gap-packages/sgpdec/commit/c4409cfe134669d850406dfbef166ca2cd0dc8b1 the conversion functions are polymorphic now documentation update and release will soon follow

[egri-nagy]

https://github.com/gap-packages/sgpdec/tree/v0.9.2