Faster get_unsafe for NTL GF(p) polynomials

[remyoudompheng]

📚 Description

Unlike similar Zmod(n) polynomials, the GF(p) NTL polynomials would call the IntegerModRing constructor for each get_unsafe call resulting in very slow polynomial evaluation.

Benchmarks:

p = next_prime(2**80)
pol = GF(p)["x"].random_element(80000)
# Before
# evaluate pol at a random GF(p) element: 260.6ms
# evaluate pol at a random GF(p^2) element: 790.1ms
# evaluate pol at a random GF(p^5) element: 1155.8ms
# After
# evaluate pol at a random GF(p) element: 66.8ms
# evaluate pol at a random GF(p^2) element: 541.2ms
# evaluate pol at a random GF(p^5) element: 889.9ms

📝 Checklist

• The title is concise, informative, and self-explanatory.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation accordingly.

[remyoudompheng]

This patch makes the 2 copies of get_unsafe for NTL_ZZ_pX consistent and is useful to make polynomial evaluation faster. It is a subset of the larger #35393

[github-actions]

Documentation preview for this PR is ready! 🎉
Built with commit: bf927cc

[mezzarobba]

I don't understand why you are removing this sig_on/sig_off pair.

[remyoudompheng]

It's a bit unrelated but calling sig_on/sig_off is slightly costly (not that much) and documentation says it should apply to possibly long computations and it seems we are not in this case since this getter does not do anything. Also __setitem__ does not do the sig_on/sig_off

I'm totally fine to split this off this pull request if you advise so.

[mezzarobba]

No, that's fine, I just wasn't sure if it was intentional. Thanks!