Clean up off-heap memory usages

[roberttoyonaga]

Summary

This PR does a bit of clean up to set the stage for further work on native memory tracking (see issue: #7631). Specifically, it replaces usages of LibC malloc/calloc/realloc/free with calls toUnmanagedMemory. From now on, I suggest that LibC not be used directly to manage memory. This will allow for NMT code to be added to UnmanagedMemorySupport implementations. Additionally, this PR specifically marks locations where memory allocated outside Java code must be freed (UnmanagedMemory#untrackedFree).

This refactoring serves a second important purpose. It helps mitigate the following pitfalls associated with "malloc headers" needed for NMT. In hotspot, the "malloc header" is an extra bit of memory allocated contiguously with the main memory payload. It contains metadata such as size and type used for NMT. I think a similar approach can be used in SubstrateVM using @RawStructures (similar to how the JFR buffers have a header and payload). A pointer to the data payload is returned from malloc and the header is transparent to the caller. Here are the pitfalls I can see:

1. If LibC#malloc() is used to allocate memory instead of UnmanagedMemorySupport, we'll miss some data that should be tracked.
2. If LibC#free() is used to free tracked memory, we'll be in trouble because only UnmanagedMemorySupport is aware of the extra header data.
3. If UnmanagedMemory#free() is called on untracked memory (off-heap memory allocated outside of Java), then we'll segfault when trying to access a header that doesn't exist.

The clean up in this PR mitigates these pitfalls, but doesn't eliminate them. If the user is determined, they can use ImageSingletons.lookup(LibCSupport.class) to use LibC directly, and they can choose to use UnmanagedMemory#free() instead of UnmanagedMemory#untrackedFree() if they ignore the Javadoc.

[roberttoyonaga]

Closed by #7883