Add list helper without memory operations

[vicLin8712]

list_pushback() and list_remove() allocate and free linkage nodes internally. This behavior prevents callers from reusing linkage nodes and also introduces extra time overhead when these APIs are used frequently.

This change introduces two new APIs with the same semantics as the original ones, but without calling malloc() or free() on the linkage nodes. These no-allocation variants allow callers to reuse pre-allocated linkage nodes and reduce the allocation overhead in hot paths.

---

Summary by cubic

Added no-allocation list helpers for pushback and remove to let callers reuse pre-allocated nodes and avoid malloc/free overhead in hot paths.

• New Features
  • list_pushback_node(list, node): inserts an unlinked node without allocating; skips nodes already linked.
  • list_remove_node(list, node): removes a node without freeing; no-op if the node isn’t in the list.
  • Renamed test_libc to test_utils and added list tests (order, removal, empty-list); updated Makefile target.

^{Written for commit 1266621. Summary will update automatically on new commits.}

[cubic-dev-ai]

No issues found across 3 files

[jserv]

Instead of using test_list.c, we can consolidate everything into test-utils.c, which covers all tests for utilities and helpers.

[HeatCrab]

I noticed that the original functions and the new helpers share the exact same traversal logic. Would it be better to let the original functions call the new helpers, instead of duplicating the logic?

[visitorckw]

The idea looks good for now.

However, in the long run, I wonder if we should consider adopting the Linux kernel approach: embedding the list node within the struct and using container_of().

This would allow us to avoid exposing dual APIs (one with internal allocation and one without). As recent fixes have shown, automatic memory allocation/deallocation can easily lead to oversight and result in memory-related bugs.