[gruenich]

Drop the DEBUGlevel debug allocator

With DEBUGlevel >= 1, superlu_malloc()/superlu_free() prepended a
size header to every block to count allocated bytes and catch double
frees. This is fully covered by AddressSanitizer, LeakSanitizer and
Valgrind, which additionally detect out-of-bounds accesses and do not
need a special build of the library. The header also shifted every
returned pointer by sizeof(double), weakening malloc's alignment
guarantee (16 bytes on x86-64) in debug builds only.

superlu_malloc()/superlu_free() are now always thin wrappers around
malloc()/free(). The CHECK_MALLOC macro, which relied on the debug
counter superlu_malloc_total, and a disabled USER_MALLOC variant that
filled new memory with 0x0F (MemorySanitizer and Valgrind find
uninitialized reads) are removed as well. USER_MALLOC/USER_FREE can
still be defined to plug in a custom allocator.

To check for memory errors and leaks, build with AddressSanitizer
(supported by GCC and Clang) and run the tests:
cmake .. -DCMAKE_BUILD_TYPE=Debug
-DCMAKE_C_FLAGS="-fsanitize=address -fno-omit-frame-pointer"
make
ctest --output-on-failure
or run a program under Valgrind, e.g.,
valgrind --leak-check=full EXAMPLE/dlinsol < ../EXAMPLE/g20.rua

[xiaoyeli]

This debug allocator was an old trick that predated valgrind and AddressSanitizer. It's a good first-order check & balance to reveal memory leak. I think it doesn't hurt to keep it. This is only used by the developers if needed. The users don't see it, because they won't set DEBUGlevel>=1

[gruenich]

I think it clutters the code. Not by much. I still think pointing people to modern tools is the better way.

It is your call, if you close this merge request, I have no hard feelings. Even Claude Code pointed out that I split the changes into two merge requests is a good idea, as "the maintainers might want to discuss" the changes of this merge request...

[xiaoyeli]

I suggest to keep this PR open.