Adds a memory_stats metrics component

[Davidbick]

What changed?

• Adds a memory_stats metrics component to the generic metrics registry, reporting FreeRTOS heap health (heap_free, heap_min_free, heap_largest_block, in bytes).

How does it make Bristlemouth better?

• Adds fleet-wide heap visibility per node and proves the generic registry takes a second producer cleanly.
• heap_min_free is a low-water leak signal, heap_largest_block catches fragmentation.

Where should reviewers focus?

• Field choice: three of the seven HeapStats_t fields, free + low-water + largest-block.

Checklist

• Add or update unit tests for changed code
• Ensure all submodules up to date. If this PR relies on changes in submodules, merge those PRs first, then point this PR at/after the merge commit
• Ensure code is formatted correctly with clang-format. If there are large formatting changes, they should happen in a separate whitespace-only commit on this PR after all approvals.

[matt001k]

I think having xNumberOfSuccessfulAllocations and xNumberOfSuccessfulFrees would be very beneficial as well. As it can help us determine if there is a leak somewhere 🥬

[matt001k]

We should also probably update the bm_posix.c file to make sure bm_sbc apps do not break.

[matt001k]

I am a bit on the fence on whether or not this should be something that bm_core handles or bm_protocol, what was the rational of placing this here rather than bm_protocol?

Also @victorsowa12 what are your thoughts on where the memory statistics should live?

[Davidbick]

I put the PR in bm_core following the ADIN component, but ADIN has its own reason to live here since core hardcodes the ADIN2111 as the network device. For memory, bm_core makes me add a bm_heap_stats() accessor to bm_os/bm_freertos; in bm_protocol I'd just call vPortGetHeapStats() directly. The one real tradeoff is that core lets memory_metrics self-register once in bristlemouth_init, whereas in bm_protocol I'd wire it into each app_main. I'm leaning bm_protocol so I am happy to move it! @matt001k @victorsowa12

[matt001k]

@Davidbick personally I am ok with either direction you want to go.
I could see benefit for it being in both, but we would have to come up with a good way for it to work in bm_posix.c.

[Davidbick]

Ended up going with bm_protocol: bristlemouth/bm_protocol#416
The heap is an integrator/RTOS concern and bm_protocol owns the FreeRTOS heap so it keeps the change out of bm_core entirely and avoids widening the bm_os contract with a bm_heap_stats() that bm_posix.c can't faithfully implement (glibc has no equivalent for min-free/largest-block/alloc counts).