remove automatic methods of polynomials in InfinitePolynomialRing

[mantepse]

Several methods only appear to work (they return elements with the wrong parent), and some don't really make sense (like exponents and degrees).

[mantepse]

I do not yet understand the failure in numerator

        Check that :issue:`37756` is fixed::

            sage: R.<a> = InfinitePolynomialRing(QQ)
            sage: P.<x,y> = QQ[]
            sage: FF = P.fraction_field()
            sage: FF(a[0])
            Traceback (most recent call last):
            ...
            TypeError: Could not find a mapping of the passed element to this ring.

[mantepse]

define_implicitly uses degrees, and KeyPolynomial uses exponents, but these do not easily make sense, because the number of variables may change over time. For example:

sage: R.<x> = InfinitePolynomialRing(QQ)
sage: p = x[1]
sage: p.degrees()
(1, 0)
sage: p*x[10]
x_10*x_1
sage: p.degrees()
(0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0)

I think we should avoid these methods, but for doing so in key_polynomial.py, I would need some help.

EDIT: in weyl_algebra.py we use monomial_coefficients, which has the same problems.

[github-actions]

Documentation preview for this PR (built with commit 05ce3ea; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[trevorkarn]

Thanks, I'll take a look!

[mantepse]

Unfortunately, the bug mentioned in #40533 (comment) along with #40540 seems to be a show stopper. If I understand correctly, the problem really is in the element_constructor of the InfinitePolynomialRing, although FractionField_generic._element_constructor also looks fishy. resolve_fractions tries various conversions, and since there are conversions between different polynomial rings that have the same number of variables, we may have surprising results.