Refactor MatrixSpace implementation

[fingolfin]

Resolves #1379
Resolves #1317

Counterpart to Nemocas/AbstractAlgebra.jl#1318 (which this requires)

Probably won't work right now, I just rebased this code I started over a year ago and then abandoned :-/

[lgoettgens]

The tests now no longer need to be removed due to #1748

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.84%. Comparing base (fd32962) to head (1ef145b).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1738      +/-   ##
==========================================
- Coverage   84.91%   84.84%   -0.08%     
==========================================
  Files          95       95              
  Lines       37281    36957     -324     
==========================================
- Hits        31657    31355     -302     
+ Misses       5624     5602      -22     

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

[lgoettgens]

All changes look good. There are some more matrix constructors that IMO should work generically with the new AA functionality and could thus be removed. A few got a comment on them.
But this can surely be postponed to a future PR

[lgoettgens]

I would expect this one to work generically

[fingolfin]

In this case that might actually be true -- but still, I'd really prefer to move forward now, and if you or someone else would like to remove further methods in a follow-up, be my guest...

[lgoettgens]

I would expect this one and the ones below to work generically

[fingolfin]

While there is a generic method, this method is actually optimized (though I don't know how effective the optimization is). I am reluctant to remove it as part of this PR. If someone would like to thoroughly test it and compare the performance (and allocations) of this code to the generic one, and then possibly (depending on the outcome) remove this here: fine by me. But I didn't want this PR to get bogged down by this kind of work (it's already been in the works for over a year at this point!)

[fingolfin]

In terms of "things we can probably remove now: also the code in src/arb has some methods like e.g. this one:

function (x::ComplexMatSpace)()
  z = ComplexMat(nrows(x), ncols(x))
  return z
end

which could go; similar code is in RealMat.jl/acb_mat.jl/arb_mat.jl.

Oh and also this could (mostly) go:

for T in [Integer, ZZRingElem, QQFieldElem, Float64, BigFloat, RealFieldElem, ComplexFieldElem, String]
   @eval begin
      function (x::ComplexMatSpace)(y::$T)
         z = x()
         for i in 1:nrows(z)
            for j = 1:ncols(z)
               if i != j
                  z[i, j] = zero(base_ring(x))
               else
                  z[i, j] = y
               end
            end
         end
         return z
      end
   end
end

The exception would be the variant taking a String. That could be implemented like this (which I am guessing would also be more efficient -- only parse the string once):

(x::ComplexMatSpace)(y::AbstractString) = x(ComplexFieldElem(y))

[fingolfin]

Ah, and we can now delete _err_dim_negative again as there are no references to it left in Nemo.