Add O(nlogn) poly division

[mariuslp]

Description

This PR adds a O(nlogn) division method for univariate polynomials, following "Modern Computer Algebra", section 9.1. It can decrease division time by more than 98% in some cases, e.g. dividing a poly of size 2^18 by a poly of size 2^14. While most ZK protocols now rely on precomputation rather than polynomial division, this still might be useful for protocols that do not use precomputation but still would like a O(nlogn) time, typically membership-based protocols that operate on very large sets.

I did not create an issue since the CONTRIBUTING.md mentions this is optional for performance improvement.

Breaking changes

• The Div implementation is now only available for polynomials defined over FftField. Given that the Mul impl is also only defined over FftField, I assume this is not a big issue. Moreover, I added the method naive_div in any case.

Possible improvements

• On my laptop, I have observed that the naive division algorithm is faster for small divisors, with degree less than 200. I have used the magic number 1 << 8 as the switch from naive to fast division, but this can be discussed.
• Technically, the naive division becomes faster again when the degree of the divisor becomes very close to the degree of the dividend, typically deg(dividend) - 70 on my laptop. However, the switch happens very late, and at this point the difference between the two methods is only of ~3 FFT multiplications, thus I did not add a check there.
• Fast division probably gains a lot of efficiency if the parallel feature is activated, since then FFT for multiplication can be parallelised. Since cargo does not allow features in patched dependencies, I could not test this. But adding a switch based on the presence of that feature is probably a smart move.
• Adding a method hensel_div to DensePolynomials could give users complete freedom over the choice of the division algorithm.

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (master)
• Linked to GitHub issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Wrote unit tests
• Updated relevant documentation in the code
• Added a relevant changelog entry to the Pending section in CHANGELOG.md
• Re-reviewed Files changed in the GitHub PR explorer