Improve performance of ConjugacyClasses for solvable groups

[fingolfin]

.. and use it in two ConjugacyClasses methods: the generic one
for finite groups, and the one for permutation groups. Also merge
the two existing "generic" methods for finite groups (they had the
same rank, which is rather brittle).

This speeds up the computation of ConjugacyClasses for e.g.

G:=WreathProduct(CyclicGroup(IsPermGroup,12), DihedralGroup(IsPermGroup,12));

from 110 seconds to 53 seconds on my laptop.

[markuspf]

This looks like a sensible change to me. For the un-initiated it might be helpful to comment on the cost of proving solvability (CanEasilyComputePcgs is kind of self-explanatory).

[fingolfin]

I added the "raw" IsSolvableGroup check here because (a) it is reasonably efficient for permutation groups, and its result can be useful in many subsequent computations, too, and (b) I felt that the existing check for IsSimpleGroup later on is not really cheaper either. But of course I might be mistaken -- but I rely on @hulpke to point that out :-)

[hulpke]

For permutation groups IsSimpleGroup is not as expensive as it might seem, as it uses tools from the composition series mechanism. In most cases order alone bails out quickly.
IsSolvableGroup should be cheap enough, as the code running afterwards effectively would discover that the group is solvable.

[fingolfin]

Here perhaps we should instead start with HasIsSolvableGroup( G ) and ..., as this code could be called on arbitrary groups. The only reason I didn't do it was that the existing method didn't do it either.

BTW, CanEasilyComputePcgs is a category, and set by some implications once the group "knows" that it is solvable. So the order of the check here is crucial.

[hulpke]

If indeed the pure pcgs code is so much faster, this is a good addition. (My past reason for not linking it in was that I was more interested in having my new code be tested.)

[hulpke]

For permutation groups IsSimpleGroup is not as expensive as it might seem, as it uses tools from the composition series mechanism. In most cases order alone bails out quickly.
IsSolvableGroup should be cheap enough, as the code running afterwards effectively would discover that the group is solvable.

[hulpke]

(I think the time overhead in the code is purely with storing informations in the centralizers about how they fit with the chosen series -- no reason to not make this change but also not to worry about the other code. It is an artifect of the huge number of classes)