sys/malloc_thread_safe: new module

[maribu]

Background

The AVR libc in master has special wrappers for malloc(), calloc(), realloc() and free() provided by @gschorcht to allow thread-safe calls to malloc() and friends. Using some linker magic, all calls to the real functions are linked against those wrappers. Hence, neither the C library nor the user code need to be touched to provide thread safety this way.

Other C libraries like newlib or picolibc optionally provide hooks that get called when entering and leaving malloc() and friends. Similar hooks exist for other functions as well. #8619 provides those hooks, so that thread safe versions of various syscalls are made available. However, presumably due to the increased per-thread RAM requirements, this PR still didn't made it to master.

@gschorcht malloc() wrappers on the other side require no additional RAM, only some ROM. And the concept easily applies to any c library. So this PR makes them available as separate module.

Contribution description

• Move thread safe implementation of malloc() and friends from cpu/atmega_common to sys/malloc_thread_safe
• Use mutex instead of disabling IRQ during critical core
  • This has two downsides: RAM consumption is increased by sizeof(mutex_t) (2 - 4 bytes) and calls to malloc() and friends from IRQ context becomes impossible
  • However: This greatly improves real time properties of the system. IMO a good trade-off
  • assert()s are added to easily detect calls to malloc() from IRQ context
• Make both cpu/atmega_common and cpu/cortexm_common depend on the new module

Future Steps

• More platforms like MSP430, RISC-V, MIPS likely should also use this. But let's do this in follow ups. It is only a matter of adding USEMODULE += malloc_thread_safe, but splitting this eases testing.
• newlib: add thread safe implementation #8619 remains useful for thread-safe implementations of all other system calls.
  • IMHO, thread safety for other system calls than malloc() and friends can be optional. This allows application developers to decide which side of the trade-off (RAM vs. thread-safety) they prefer. E.g. most of the time I don't care about garbage from STDOUT, or being able to only access files from a single thread.
  • The dependency to malloc_thread_safe could be dropped when newlib_thread_safe is used
  • This malloc wrappers get garbage collected, if unused. So only applications doing dynamic memory management have to pay the toll.

Testing procedure

The test provided by #15598 is included in this PR and should now pass for Cortex-M boards.

Issues/PRs references

Includes #15598

Provides in part what #8619 aims to do. (And should not conflict with it. User should be able to pick #8619 over this.)

[benpicco]

looks good to me.
The overhead is minimal and only has to be payed if malloc & friends are used at all.

Tests did all pass, so that should be good.

codespell found some typos - please squash those in directly.

[maribu]

Thanks :-)