lib: add cbprintf capability

[pabigot]

This PR adds a C99 stdio value formatter capability named cbprintf() (plus related variants) where generated text is emitted through a callback. This allows generation of arbitrarily long output without a buffer, functionality that is core to printk, logging, and other system and application needs.

The formatter supports most C99 specifications, excluding:

• %L[aefg] long double conversion
• wide character output

The new solution is derived from z_prf(), which had the most complete functionality available. Format parsing has been reimplemented, while floating point conversion has been retained and enhanced.

Kconfig options allow disabling features like floating-point conversion if they are not necessary.

Benefits include:

• No more inconsistencies between printk, logging, and shell formatting capabilities.
• Reduced inconsistencies due to toolchain libc capabilities.
• Simplified (toolchain-independent) formatting feature selection via Kconfig.
• Core infrastructure can avoid duplication with libc printf by using cbprintf variants.
• Potentially a path to resolving logging: 32 bit float values don't work. #18351 and related issues, as the infrastructure can tell a caller the total size of arguments to the conversion string.
• Fixed bugs with several specifications.

Costs include:

• Applications that used only printk with no extra features consume more code space than the previous implementation.

Fixes #29202

[nashif]

LGTM, this is similar to what I was trying to do with just the moving things around :)

https://github.com/zephyrproject-rtos/zephyr/compare/master...nashif:zprf_vprintk?expand=1

[andrewboie]

this looks great.
I'm assuming stack usage for printk() is roughly like it was before? Passing CI result suggests to me that it does, but I thought I'd ask.

[andrewboie]

this looks great.
I'm assuming stack usage for printk() is roughly like it was before? Passing CI result suggests to me that it does, but I thought I'd ask.

[andrewboie]

this looks great.
I'm assuming stack usage for printk() is roughly like it was before? Passing CI result suggests to me that it does, but I thought I'd ask.

[andrewboie]

this looks great.
I'm assuming stack usage for printk() is roughly like it was before? Passing CI result suggests to me that it does, but I thought I'd ask.

[pabigot]

this looks great.

Thanks!

I'm assuming stack usage for printk() is roughly like it was before?

I expect it's a little larger compared to z_vprintk, but smaller for z_prf(), depending on how much the compiler could overlay the local variables. I don't know of any easy way to get real data.

[npitre]

``` +/* We can't determine at build-time whether int is 64-bit, so assume + * it is. If not the values are truncated at build time, and the str + * pointers will be updated during test initialization. + */ +static const unsigned int pfx_val = (unsigned int)0x7b6b5b4b3b2b1b0b; ``` In the Zephyr environment, an int is always 32 bits. Only a long will vary in width, and sizeof(long) is always equal to sizeof(void*). So the constant above will always be truncated.