WIP: Speed up PowMap

[fingolfin]

Contributes towards #5. On my M1 MacBook pro, the example there takes 52 seconds in a fresh GAP session with master of this package; with this PR it takes 33 seconds.

This is a draft for multiple reasons. It has not yet been tested thoroughly, it is not sufficiently documented, it could be more general, and finally it may be possible to replace some or all of it with calls to GAP library functions (@ThomasBreuer may know).

Currently this PR consists of quick hack that speeds up computing the powermap for elements with prime order. In the example above the first element being dealt with is one of prime order 307. Without this code, FindClass is called on elements of order 307 about 305 times. But there are "only" 102 classes of order 307. The new code exploits that the unit group $U$ of $\mathbb{Z}/307\mathbb{Z}$ acts on these classes, and $U$ is itself cyclic of order 306. We end up calling FindClass only 102 times before a cycle in the action of $U$ is detected. At that point the powermap can be completed super cheaply.

A second win comes from the observation that before we reach the original class again, there are no loops, and thus FindClass need not consider classes we used before.

With this PR, the places where we are inside LLL or post-processing LLL suddenly stand out much more (it might be useful to add in some code which computes an aggregate of how much time is spent in FindClass vs. LLL vs. other code path. Or we use the profiling package...).

To adapt this to the non-prime case, a natural next step would be to deal with elements $g$ whose order is a prime power $p^k$. There basically, for $i=0,\dots,k-1$ one can apply a similar trick by considering the orbit of $(\mathbb{Z}/p^{k-i}\mathbb{Z})^*$ on powers of $g^{p^i}$. And then finally similarly for arbitrary moduli.

But it doesn't make sense to work on that if @ThomasBreuer tells me it is all already there somewhere ;-)

[codecov]

Codecov Report

Attention: Patch coverage is 95.65217% with 2 lines in your changes missing coverage. Please review.

Project coverage is 84.07%. Comparing base (fc0e5bb) to head (73d245a).

Files with missing lines	Patch %	Lines
lib/InduceReduce.gi	95.65%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #10      +/-   ##
==========================================
+ Coverage   83.10%   84.07%   +0.97%     
==========================================
  Files           6        6              
  Lines         515      559      +44     
==========================================
+ Hits          428      470      +42     
- Misses         87       89       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[fingolfin]

Another thought: the code spends some effort on computing the powermap for an element of order 288; as a side effect it of course also considers powers of that element of orders 32, 16, 8, 4, 2, 1. It then does that again for order 16, 8, ...when it deal with a starting element of order 272; and then it directly handles several elements of order 16.

This suggests a more holistic approach may be useful. At the very least, the powermaps for these elements of smaller order should also be stored and re-used.

Or maybe one needs to actually understand the algorithm (I must admit I did not even read the paper :-/) and take a step back and do it completely differently...