core: unlink objects before destruction

[edsiper]

Summary

• unlink list-owned profile objects when their public destroy functions are called directly
• make profile and resource destruction null-safe, consistent with the other destroy APIs
• add a lifecycle regression covering direct and bulk child destruction across the object hierarchy

Root cause

Most child constructors immediately attach their objects to a parent cfl_list, but their public destroy functions freed the object without removing its list node. Direct destruction therefore left a dangling parent entry. Traversing or destroying the parent later could dereference freed memory or free the object again. The existing attribute-unit destructor already had the required orphan check, but the other list-owned types did not.

The regression reproduced the original behavior as free(): double free detected in tcache 2.

Impact

Callers can safely destroy linked samples, sample types, mappings, locations and lines, functions, links, profiles, scope profiles, and resource profiles independently. Parent cleanup still works for already-unlinked objects. Public structure layouts and encoded formats are unchanged.

Validation

• GCC build and CTest: 4/4 passed
• Clang build and CTest: 4/4 passed
• GCC AddressSanitizer + UndefinedBehaviorSanitizer build and CTest: 4/4 passed
• Valgrind full test sweep: all four test executables passed with definite and indirect leaks treated as errors
• focused Valgrind lifecycle regression with all leak kinds treated as errors: passed
• git diff --cached --check

A Clang sanitizer run was also attempted, but the pre-existing profile test hung under that local runtime. The non-sanitized Clang run and GCC sanitizer run both completed successfully.