heap: add heap implementations for SRAM and CCM SRAM

This provides an abstraction for pios drivers to allocate RAM.

The normal SRAM heap is DMA-safe.  The CCM SRAM heap is NOT DMA-safe.
link map: add heap segment for f1 bootloaders
makefile: add pios_heap.c to all BL and FW builds
heap: use pios malloc in common drivers
ut logfs: adapt logfs unit test to pios_malloc API
heap: use pios heap in f1 drivers
heap: use pios heap in f3 drivers
heap: use pios heap in f4 drivers
fast heap: enable support for fast heap on f3 and f4 targets

The STM32F3 and STM32F4 SoCs support a fast (zero wait state)
RAM called CCM RAM.  Enable usage of this RAM in PiOS for these
systems.
uavobjmgr: use fastram for uavo and event structs

Saves 5KB of regular heap on flyingf3
heap: use independent pios heap for bl and fw

PIOS_malloc() no longer depends on FreeRTOS but rather provides
a full implementation of the APIs that FreeRTOS expects from a
heap allocator.
heap: use sim-specific version of pios_heap
heap: use logfs-specific version of pios_heap
board-info: drop all defines for max devices

Device instance memory is now dynamically allocated even when
FreeRTOS is not in use.
heap: reserve early init heap space in linker map for f1

The F1 targets use the tail of the heap as the stack for the
init code and then after init, this RAM is added onto the heap.

This init dance was relying on a statically allocated
standard heap.  The new heap allocator doesn't statically
allocate it but rather relies on the _sheap and _eheap
symbols being correct.

This change forces the linker to reserve some portion of the
heap to be available during init.