Optionally borrow polynomial coefficients

[jan-ferdinand]

Refactor polynomials to (a) make their innards private and (b) turn their innards into a clone-on-write slice, reducing the number of allocations needed for read-only operations like polynomial evaluation.

Pros

• Certain functions, like evaluation, can happen without owning the coefficients, which reduces memory consumption.
• There are fewer sneaky memory allocations, i.e., it is more obvious in calling code whether allocations are happening. [^exceptions]

Cons

• Explicit lifetimes are required more often.
• Polynomial's implementations of traits Zero and One are less usable now. Should poly.is_zero() be unusable due to lifetime constraints (“poly escapes the method body”), you can use poly.degree() < 0 instead.

A lot of lines have changed only because of re-grouping to avoid multiple impl blocks with the same trait & lifetime bounds. Commit 65914d5a736cce472080b12a168b4ef5d22820f only makes the polynomial's innards private to simplify review.

Performance

The benchmark suite indicates some improvements, some regressions, and I can't seem to identify clear patterns. I will try to make sense of the results and report back in a separate comment.

[^exceptions]: Methods taking &mut self, like scalar_mul_mut() or normalize(), are unfortunate exceptions if called on a Polynomial::new_borrowed(). I thought about making those methods consuming, and return a Polynomial<'static, FF>, but have decided against that for now. Let me know if you disagree with that decision.

[jan-ferdinand]

@aszepieniec, @Sword-Smith, I have requested both of you for review only because I'm not sure who this is better suited for. :relieved:

[coveralls]

coverage: 97.747% (-0.06%) from 97.81% when pulling 65914d5a736cce472080b12a168b4ef5d22820fc on poly_cow into 4af2ffa374d3be18ae6617f702ec889c92c8d920 on master.

[Sword-Smith]

Let me know if/when you need me to run benchmarks.

[jan-ferdinand]

Performance

• scaling a base-field polynomial by a base-field scalar is faster by about 9% (in use)
• constructing a zerofier the “smart” way is slower by about 2% (not in use)
• constructing a zerofier the “fast” way is faster for some instances, by about 5% (in use)
• constructing a zerofier the “naive” way is faster for larger instances, by up to 8% for the largest instance (not in use)
• other performance changes are less than 2%
• most of those other performance changes are not consistent across instance sizes, making them less relevant in my eyes

In my eyes, this PR is ready to be merged.