Soliciting design advice/opinions: speed-and-memory-hungry vs. slow-but-sure

[JohnAAbbott]

Is your feature request related to a problem? Please describe.
The current prototype for is_unimodular(::ZZMatrix) chooses between two approaches: one is fast but can require lots of RAM, the other requires relatively little RAM but can be markedly slower (e.g. factor of 100). It is not possible to reduce the RAM requirement of the fast method.

Describe the solution you'd like
What should the default behaviour be? Would it be confusing to offer an optional parameter indicating that the slow method should be used if expected RAM requirements exceed some limit? How to specify the limit?

Describe alternatives you've considered
If the fast method exhausts the RAM available then an error occurs, and it might leave Oscar/Julia in an "unhappy" state (not entirely sure about this). If the slow method is taking too long, it can be interrupted in the usual way (e.g. ctrl-C), and this will likely leave the Oscar session in a stable state.

Additional context
I'm only seeking opinions, and suggestions of aspects to consider. The problem arises only for quite large matrices. The simplest solution is to choose the method based solely on estimated computation time, and ignore possible memory exhaustion problems (which depend on the resources available on the running platform).

[JohnAAbbott]

My understanding, from discussions last week, is that we modify the function (is_unimodular in this case) so that the caller can specify which subalgorithm to use, e.g. via an algorithm kwarg. The documentation must then explain which options are available for algorithm and what behaviour they exhibit. Obviously, in the absence of the kwarg the algorithm choice will be made automatically -- the decision may or may not be based on the actual input data (for is_unimodular the decision is based on the matrix passed in as argument).
The code in Nemocas/Nemo.jl#1991 incorporated the changes described above.