Fix IsMonomialMatrix for compressed matrices

[fingolfin]

Note that for MatrixObj implementations which are not lists, doing for row in M do may not work anymore (unless we decide to officially define that Iterator(matobj) shall return a row iterator).

Fixes #3148

We could backport this, the change should be safe enough; but since this is an ancient bug, there is no urgent need to do it either.

[coveralls]

Coverage decreased (-0.0009%) to 82.827% when pulling 6780172 on fingolfin:mh/IsMonomialMatrix into cf47710 on gap-system:master.

[codecov]

Codecov Report

Merging #3149 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master    #3149   +/-   ##
=======================================
  Coverage   83.66%   83.66%           
=======================================
  Files         687      687           
  Lines      336685   336685           
=======================================
  Hits       281697   281697           
  Misses      54988    54988

Impacted Files	Coverage Δ
lib/matrix.gi	86.85% <100%> (+0.08%)	⬆️
hpcgap/lib/hpc/stdtasks.g	71.77% <0%> (-0.41%)	⬇️

[ThomasBreuer]

I would say the real bug in this situation is that BlistList resp. the kernel function BLIST_LIST
runs into an error if the first argument is a compressed matrix, such as an element of SL(2,2).
Note that compressed matrices are in the filter IsList and IsDenseList, thus calling BlistList for such a matrix is allowed, according to the documentation.

I understand the proposed change as follows.

• Using BlistList in the given situation --if it would work-- would be expensive and thus should be avoided. (It seems that ListWithIdenticalEntries( l, false ) is faster than BlistList( l, [] ), even for plain lists l and even if one would additionally call ConvertToBlistRep; should the use of BlistList perhaps be deprecated, or restricted to specific situations?)

• The comment talks about the IsMatrixObj setup, which is not related to the code change. My interpretation is that a proper fix in this more general context will anyhow require more code changes.

In this sense, the proposed change can in principle be approved.

It would be good to address also what I had called the real bug above (in a separate pull request, without backport to GAP 4.10), perhaps by adjusting the documentation of BlistList to the reality such that the first argument is restricted to certain types of lists.

[fingolfin]

I have no submitted a separate issue #3155 for the BlistList and UniteBlistList issue. I will also submit another PR which optimizes these two functions for the case where the sub list is empty.

[fingolfin]

Backported to stable-4.10 via 18edc7f