core: add stdio.h to replace stdout functions with stdio_null

[benpicco]

Contribution description

So far stdio_null would just drop the stdio backend, all the expensive stdio formatting functions were still included.

This PR replaces all calls to printf() and friends with a no-op.

Testing procedure

Build e.g. tests/minimal which uses stdio_null:

master

   text	   data	    bss	    dec	    hex	filename
   9256	    108	   1312	  10676	   29b4	/home/benpicco/dev/RIOT-2/tests/minimal/bin/same54-xpro/tests_minimal.elf

this PR

   text	   data	    bss	    dec	    hex	filename
   5140	    108	   1312	   6560	   19a0	/home/benpicco/dev/RIOT/tests/minimal/bin/same54-xpro/tests_minimal.elf

Issues/PRs references

[maribu]

lgtm. The CI has complaints, though

[riot-ci]

Murdock results

✔️ PASSED

1280166 dist/tools/headerguards: ignore if #include_next is used

Success	Failures	Total	Runtime
10214	0	10215	16m:42s

Artifacts

• Documentation preview

[chrysn]

That's a GNU extension, AIU supported by Clang as well.

I'm not saying we shouldn't do this (I'm glad of all libc headers we can do ourselves to avoid weird choices by the used libc), but it is in direct conflict with the first bulled of the coding convention. But if we start doing it, better change the code convention (or if that's what we do get a 2-ACK dispensation), and reap the fruit by using #pragma once, rather than creating a divide between what we do and what we claim to do.

[maribu]

+1 for updating the coding convention to match.

We actually already have an used of #include_next in the AVR code to automatically move format string to flash and use printf_P() to save lots of RAM.

[benpicco]

I added a line to CODING_CONVENTIONS.md.
I think being implemented by both GCC and Clang is enough of a safeguard to prevent opening the gates to some crazy things.

[benpicco]

We already use #include_next in esp32, tinyusb, posix and avr8_common - is the stdio case really any different?

[chrysn]

I'd be more lenient in the cpu directories where there might easily just not be compilers other than the CPU specific one (AIU, neither ESP32 nor AVR can be built with off-the-shelf C compilers). Similarly in the POSIX case, its use is limited to native, which AIU also comes with a severe set of limitations by construction.

As for tinyusb and POSIX, I'd guess that neither reviewer nor author took care.

[maribu]

AVR can use upstream GCC (and we do so). Upstream clang is rather mature, but not feature complete.

ESP does indeed need magic binary only compilers.