Fix StandardAssociateUnit for polynomial rings to return a polynomial, not an element of the coefficient ring

[fingolfin]

By definition in the documentation, the returned unit must be an element of the ring.

The drawback of this is that it makes StandardAssociateUnit a bit less efficient: converting the unit into a polynomial introduces overhead in terms of memory and runtime. And for typical applications of this (e.g. implementing row reductions in a matrix), it doesn't matter, as all we really need is that for inputs a and b we get a "unit" u such that a * u = b and a = b * u^-1 hold.

So an alternative to this PR would be to adjust the documentation, and also checkStandardAssociate.

Thoughts, anybody?

[codecov]

Codecov Report

Merging #3611 into master will decrease coverage by 12.36%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           master    #3611       +/-   ##
===========================================
- Coverage   84.64%   72.27%   -12.37%     
===========================================
  Files         698      635       -63     
  Lines      345549   308790    -36759     
===========================================
- Hits       292482   223174    -69308     
- Misses      53067    85616    +32549

Impacted Files	Coverage Δ
lib/ratfunul.gi	83.36% <100%> (-2.4%)	⬇️
lib/ringpoly.gi	71.59% <100%> (-5.57%)	⬇️
lib/teachm2.g	15.38% <0%> (-84.62%)	⬇️
lib/ctblauto.gi	5.98% <0%> (-83.67%)	⬇️
lib/helpt2t.gi	0.23% <0%> (-83.14%)	⬇️
lib/proto.gi	1.03% <0%> (-82.48%)	⬇️
src/compiler.c	8% <0%> (-80.68%)	⬇️
lib/ctbllatt.gi	0.81% <0%> (-79.99%)	⬇️
src/trans.h	7.69% <0%> (-78.03%)	⬇️
lib/algliess.gi	0.99% <0%> (-74.54%)	⬇️
... and 383 more

[coveralls]

Coverage increased (+0.01%) to 84.405% when pulling 14b7293 on fingolfin:mh/zmodnz-polynomial into 659250f on gap-system:master.

[wilfwilson]

So an alternative to this PR would be to adjust the documentation...

What would the documentation say in the case? Something like

...returns a unit in some ring whose elements can be multiplied with those of R with the property that..."?

I think it would also need an explanation for why it was this way, otherwise it would seem a bit weird.

To be honest I don't really mind, I've never used this function directly and don't think I would do anytime soon. From my mathematical point of view, I think I prefer the behaviour and documentation as this PR makes things.

I understand the inefficiency side of things. Could this be perhaps accommodated with another function with a different name?

[fingolfin]

I suggest we backport this to 4.11, simply because several other fixes for StandardAssociateUnit are already in there. However, if people prefer to defer this to 4.12, I don't mind either.

[hulpke]

Yes, please backport.

[fingolfin]

Backported in commit a3d9c0a