Make nmod_geometric_progression faster with Shoup precomputation if possible

[maelhos]

This draft aims at improving the recent nmod_geometric_progression by using Shoup's precomputed form (as mentioned by @fredrik-johansson in #2449 .

For now, the precomputations are done on each vectors of constants when possible (when high bit of modulus is not set).

[vneiger]

Unfortunately, in my measurements this does not bring much. We could have hoped for some interesting speed-up in small lengths (the part that benefits from Shoup's precomputations only involves a linear number of nmod multiplications, so we expect it to be negligible in front of the polynomial multiplication as soon as the length is not too small). But even for small lengths it is not very interesting:

len     points |AFTER   BEFORE
1             1|3.1e-02 3.3e-02
2             2|4.3e-02 4.5e-02
3             3|5.9e-02 6.3e-02
4             4|7.0e-02 7.4e-02
6             6|1.0e-01 1.1e-01
8             8|1.4e-01 1.5e-01
10           10|1.8e-01 1.9e-01
12           12|2.9e-01 3.1e-01
16           16|5.9e-01 5.7e-01
20           20|6.9e-01 7.1e-01
30           30|1.3e+00 1.3e+00
45           45|2.5e+00 2.5e+00
70           70|5.3e+00 5.3e+00
100         100|9.6e+00 9.7e+00
200         200|1.5e+01 1.5e+01
400         400|2.6e+01 2.6e+01
800         800|5.2e+01 5.2e+01
1600       1600|1.1e+02 1.1e+02
3200       3200|2.3e+02 2.2e+02
6400       6400|4.5e+02 4.6e+02

Maybe it's not so nice to double the amount of storage for the precomputations for a marginal gain like this. Also, for lengths below about 10 it seems faster to use the naive iterative evaluation anyway.

[vneiger]

One place where Shoup's precomputation could help is in the precomputation stage itself. Similarly to what is done for nmod_vec_invert. That function is still fresh in my mind so I'll give it a try.