Trac #15229: Improved use of category framework for IntegerModRing

On [https://groups.google.com/forum/#!topic/sage-devel/IeIeHsnNIf4 sage-
devel], some discussion on `IntegerModRing` and its relation to
categories took place. I would summarize the discussion and its
consequences as follows:

- It should be possible for the user to indicate that the modulus of an
`IntegerModRing` is prime, so that the ring is a field, without Sage
performing a primality test. However (not part of the discussion)
`GF(n)` does a primality test (actually it factors n---is this really
needed?). So, the user can not simply use `GF(n)` if n is a huge number
that the user knows to be a prime number.
- It was suggested that the user can instead do `IntegerModRing(n,
category=Fields())`. This feature was asked for in #8562 and implemented
in #9138.
- `.is_field()` should do a primality test, unless it is already known
that the ring is a field. It has been suggested in the discussion on
sage-devel to let `.is_field()` change the category of the ring. At the
time of the discussion, this did not seem possible, but in #11900 this
feature has been added.

By #11900, refinement of category happens when it is tested whether the
`IntegerModRing` is a field by `R in Fields()`. However, there is some
inconsistency:
{{{
sage: S = IntegerModRing(5)
sage: S.category()
Join of Category of commutative rings and Category of subquotients of
monoids and Category of quotients of semigroups and Category of finite
enumerated sets
sage: S in Fields()
True
sage: S.category()
Join of Category of fields and Category of subquotients of monoids and
Category of quotients of semigroups and Category of finite enumerated
sets
sage: R = IntegerModRing(5, Fields())
sage: R.category()
Join of Category of fields and Category of subquotients of monoids and
Category of quotients of semigroups
}}}
I think we would want that `R` and `S` are in the same category after
the category refinement of `S`.

So, the '''first aim''' of this ticket is to make the categories
consistent.

Secondly, comparison of `IntegerModRing` includes comparison of types.
Originally, this has been introduced since one wanted `GF(p)` and
`IntegerModRing(p)` evaluate differently. However, changing the category
changes the type, and thus changes the ==-equivalence class. I think
this must not happen. Hence, the '''second aim''' of this ticket is to
make == independent of the category, while still letting `GF(p)` and
`IntegerModRing(p, category=Fields())` evaluate unequal.

Thirdly, in the discussion on sage-devel, it was suggested to refine the
category of R when `R.is_field()` returns true. Currently, refinement
only happens when `R in Fields()` returns true. So, the '''third aim'''
of this ticket to do the refinement as suggested.

Cc to John Cremona, since it was he who brought the "category refinement
in `is_field()`" topic up...

URL: http://trac.sagemath.org/15229
Reported by: SimonKing
Ticket author(s): Simon King
Reviewer(s): Jean-Pierre Flori

Author: Release Manager