memory corruption in C pointing to preCICE

### Page URL (if applicable)

_No response_

### What should be improved?

We should start gathering some runtime errors that may be misunderstood as a preCICE error.

A good example is the heap consistency checking in C, which is only occasionally checked to prevent impacting performance too much.

That also means that sometimes a crash/memory corruption in the Solver is only visible lateron.
In this example trace from https://github.com/precice/precice/issues/2583, the unloading of the shared object, destroys the still existing static participant (in the C bindings), which then triggers a free, which finally triggers the memory checks and emits the error:

```
#28 malloc_printerr ("corrupted double-linked list")
#29 unlink_chunk
#30 malloc_consolidate
#31 _int_free_maybe_consolidate
#33 __GI___libc_free (mem=0x...)
(Then the actual free happens that triggers the check)
#34 libprecice.so.3
... (frames 35-39 in libprecice.so.3, unresolved)
#40 precice::Participant::~Participant () from libprecice.so.3
#41 libprecice.so.3
(Shared object needs to destroy static objects)
#42 __cxa_finalize
#45 _dl_call_fini
```

Do note that a free here only happens when the participant wasn't finalized before, so this could just be a followup error.

For a better output, one can set the environment variable `MALLOC_CHECK_=1 to` avoid these delayed checks.
[sourceware.org/glibc/manual/2.44/html_node/Heap-Consistency-Checking.html](https://sourceware.org/glibc/manual/2.44/html_node/Heap-Consistency-Checking.html)

Review the website's existing troubleshooting or runtime-error documentation and the linked preCICE issue 2583 first. Add guidance explaining that delayed C heap checks and shared-object cleanup can make solver memory corruption appear to originate in preCICE, including the MALLOC_CHECK_ setting and the documented trace context; done means the guidance is published in the appropriate page.

Written by the indexing model from the issue text.