Add ring conformance tests for ad-hoc / mutating operations

[lgoettgens]

The interface states that these may be implemented by a ring, but the generic promotion code should handle them in the fallback case (see https://nemocas.github.io/AbstractAlgebra.jl/dev/ring_interface/#Optional-binary-ad-hoc-operators).

One approach to implement this is already laid out in #1814 (comment).

x-ref Nemocas/Nemo.jl#1876 (comment) by @fingolfin

[fingolfin]

The tests for adhoc operations should not just cover add!, mul! etc. but in fact also in general adhoc arithmetic involving +, *, - etc.. Ideally as part of the ring conformance tests. Indeed I'd argue the latter is less work and more important, as I expect over time more and more ring types will implement the high-level adhoc arithmetic in terms of the lower level adhoc unsafe ops like add! etc.

One missing ingredient: a way to specify for each ring R we test a list of other rings [R1, R2, ...] such that arithmetic between elements of type R and R1, etc. should be tested.

Initially we could just use a static list consisting of only AbstractAlgebra.ZZ; we could then also add AbstractAlgebra.Integers{Int} and AbstractAlgebra.Integers{UInt} and maybe also e.g. AbstractAlgebra.Integers{Int8} to have at least one "exotic" Julia integer type in there as well).

To make it more flexible, I see at least two possibilities:

• an argument to test_NCRing_interface (and then also all the others calling it) specifying additional "adhoc partner rings"
• a global function that takes a ring (or ring type?) and returns such a list (so we'd be defining methods for that everywhere.

Then we could have tests like this (assuming R is the ring being tested):

  for S in adhoc_partners
    s0 = zero(S)
    r0 = zero(R)
    s1 = one(S)
    r1 = one(R)
    for i in 1:reps
      s2 = test_elem(S)
      r2 = R(S)
      x = test_elem(R)
  
      for (r,s) in ((s0, r0), (s1, r1), (s2, rs))
        @test r == s
        @test s == r
  
        @test x + s == x + r
        @test s + x == r + x
  
        @test x - s == x - r
        @test s - x == r - x
  
        @test x * s == x * r
        @test s * x == r * x
      end
    end
  end

Of course this would still miss a ton of things (e.g. divexact) but at least it'd be a start.