PICO_MALLOC_TRACK_PEAK, peak allocation tracking for malloc

[cellularmitosis]

This PR implements a peak allocated bytes tracking option for malloc.

To enable:

target_compile_definitions(my_project PRIVATE PICO_MALLOC_TRACK_PEAK=1)

Usage: determining the peak allocated bytes during a block of code / call-stack:

malloc_reset_peak();
unsigned char* m1 = malloc(1000);
unsigned char* m2 = malloc(2000);
unsigned char* m3 = malloc(3000);
// this simply prevents the compiler from optimizing out the malloc calls:
if (m1 == NULL || m2 == NULL || m3 == NULL) {
    printf("malloc failed");
}
free(m1);
free(m2);
free(m3);
printf("malloc peak: %u bytes", malloc_peak_bytes);

which will print:

malloc peak: 6024 bytes

[peterharperuk]

Looks interesting

[cellularmitosis]

Some additional info about mallinfo, for folks interested in the subject of heap usage: https://forums.raspberrypi.com/viewtopic.php?p=2071251#p2071251

The fields that appear to matter are arena and either of uordblks or fordblks. arena does not cover all of RAM, and in fact appears to be initially 0, increased as necessary by invocations of malloc(). From what I've seen, the value of arena can be viewed as a high watermark for heap usage during the lifetime of the app -- but I don't know if that is always true after an app has done a lot of malloc()-ing and free()-ing over a long period of time.

uordblks is the amount of heap currently allocated -- space that has been malloc()-ed but not yet free()-ed. fordblks is the size of free space in the arena. I haven't always checked, but every time I have looked, it's been true that arena == uordblks + fordblks.

[slimhazard]

Some additional info about mallinfo, for folks interested in the subject of heap usage:
https://forums.raspberrypi.com/viewtopic.php?p=2071251#p2071251

It should be pointed out that the author of that forum post (that would be me) was not sure if mallinfo is always guaranteed to work that way. Said author is still not sure, it all depends on how malloc() and mallinfo() work. If an app does a lot of malloc()ing and free()ing, it is not hard to imagine that non-contiguous allocated and freed portions of the heap could result in such a way that the mallinfo numbers don't add up so neatly.

It's worth looking into, because malloc_peak_bytes would be valuable. The truth is in the newlib source code. It would also help to test an app that causes some heap fragmentation with malloc() and free(), and then check what mallinfo says.