Fix copy/deepcopy for generic matrices

[thofma]

Closes Nemocas/Nemo.jl#651

[rfourquet]

This works for generic matrices, but it removes copy on Nemo matrices... Sure this could be fixed by re-implementing copy on Nemo matrices, but this is unsatisfying to have to re-implement the same algorithm all over. I suggest we define a function which, given a matrix, returns an unitialized matrix of the same type over the same ring. I'm not sure how it should be called.

One option being to switch back similar to do just that: this very example shows that having similar return an object of the same type as the input when possible can be the desired behavior.

[thofma]

There is nothing unsatisfying with it. It will not be the same algorithm "all over" anyway since it will have to call into the C libraries. I will just add copy to Nemo matrices. We want this anyway, since the "generic" version is too inefficient.

[rfourquet]

There is nothing unsatisfying with it.

It's better to be generic when possible. In this very PR, I agree this is not so terrible as you repeat the algorithm only twice. But besides Nemo, it would be nice to automatically provide copy and deepcopy for custom matrices (I don't know whether many custom matrices are/will be implemented though).

But if copy has to be re-implemented for Nemo matrices anyway, I suggest that we do just that and not touch the AA code, which works well as it is. Then we can document that if similar is implemented in a way that doesn't preserves the input type, then copy/deepcopy has to be implemented.

[thofma]

The function deepcopy for AbstractAlgebra matrices is broken once one does using Nemo. This is a bug in AbstractAlgebra. This PR here fixes it.

How would you fix this in Nemo? Implement copy(::Generic.MatSpaceElem{fmpz}) in Nemo? This is not an option.

[rfourquet]

Implement copy(::Generic.MatSpaceElem{fmpz}) in Nemo?

Sure not, sorry I overlooked this issue. In this case, to avoid duplication between MatSpaceElem and MatAlgElem, you could also call _similar, which is like similar but guarantees to return the same element type.

I won't ask again, but you don't consider changing back similar right? In Base, copy(::AbstractArray) is defined in terms of similar, and in the docs we find statements like "guaranteeing that input and output are of the same type"... This seems to suggest that there is some kind of assumption about what similar returns that we don't support, even though it's not crystal clear in the docstring for Base.similar.

[thofma]

I have updated the PR to use _similar.

No I don't consider changing back similar in this way and I don't want to rehash this discussion.