Add more setcoeff! methods and use them to deduplicate PolyRingElem constructors

[lgoettgens]

Unfortunately this won't work as I try to access attributes/parents of elements in setcoeff! before they are set.
I see two ways to resolve this issue:

1. All element constructors should get a parent. This will be a bigger change, in particular if we want to have this consistent for all poly types.
2. setcoeff! gets an optional fourth argument, that is a UInt for nmod_poly-based types and a fmpz_mod_ctx_struct for fmpz_mod_poly-based types. If this fourth argument is not passed, we can reconstruct it (in many cases, but not inside of the constructors as parents are not available).

I would tend to 2 for now, and maybe remove this fourth argument again once 1 has made enough progress. What do you think @fingolfin ?

[codecov]

Codecov Report

Attention: Patch coverage is 84.48276% with 18 lines in your changes missing coverage. Please review.

Project coverage is 87.95%. Comparing base (9964b3e) to head (fb72d15).

Files with missing lines	Patch %	Lines
src/flint/fmpz_mod_abs_series.jl	33.33%	6 Missing ⚠️
src/flint/fmpz_mod_rel_series.jl	37.50%	5 Missing ⚠️
src/flint/nmod_abs_series.jl	66.66%	3 Missing ⚠️
src/flint/nmod_rel_series.jl	66.66%	3 Missing ⚠️
src/flint/fmpz_mod_poly.jl	90.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1911      +/-   ##
==========================================
- Coverage   87.98%   87.95%   -0.03%     
==========================================
  Files          99       99              
  Lines       36464    36279     -185     
==========================================
- Hits        32082    31911     -171     
+ Misses       4382     4368      -14     

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

[lgoettgens]

This now implements option 2 of the initial message.

[fingolfin]

Sorry I didn't realize this was waiting for feedback from me :-(.

Option 2 sounds fine to me. Not even sure we need / want to go to option 1, but as you say, option 2 would be a somewhat natural stepping stone towards that as well.

[fingolfin]

Should ctx be another (fourth) argument or a kwarg?

The advantage of a kwarg is that it helps understanding what's going on, esp. in the cases were ctx is another integer. If I see set!(z, 3, c, R) it is somewhat more opaque than set!(z, 3, c; ctx=R).

Alas, in the end, all of these are low-level unsafe helpers. I can happily live with either variant.