Investigate and correctly re-size FreeRTOS Task Stack Allocation

[ManushPatell]

All three current tasks in (main.cc) front controller -> task_100hz, task_10hz, task_1hz share one stack size constant.

static const size_t STACK_SIZE_WORDS = 2048 * 16; // = 32,768 words = 128KB per task

That's 128KB per task, and a total of 384KB of RAM out of the 512KB of ram we have available on the STM32F7. I need to determine how much of this stack is actually being used and how much is vacant because in developing the canflash bootloader #583, we utilize a chunk of RAM to receive a buffer of flash firmware from our RPI. I've allocated around a firmware buffer of 256KB, which may seem overkill but I'll need to verify that as well. However at the moment, I've reached a point where there is not enough RAM for the bootloader to receive firmware soooo its time we trim down...

What's already been done

Linked in #590 is a method of actually measuring stack usage at runtime, using FreeRTOS's built-in uxTaskGetStackHighWaterMark() API. Each task will now track the lowest amount of free stack it has every observed in a static UBaseType_t min_hwm variable per task, updated once per loop.

What needs to happen

1. Flash this build to our front controller
2. Run the vehicle through as many real states/conditions as possible (not just IDLE). Try to go through normal driving state, an error path, startup and shutdown sequences. The whole point is capture the worst case stack depth
3. Read out the three min_hwm values using a debuggers live memory view (I think platformio debugger should work for this) while the target is running.
4. Compute the real stack usage per task: STACK_SIZE_WORDS - min_hwm = words actually used at the deepest point observed
5. Pick a better, more efficient STACK_SIZE_WORDS per task - multiply this usage by 1.5-2.0x for safe margins.
6. Update the task creation calls (xTaskCreateStatic(...)) and the buffer arrays to test the smaller values (look for debug led set high, signals a stack overflow)